<!DOCTYPE html>
<!--
==============================================================================
           "GitHub HTML5 Pandoc Template" v2.1 — by Tristano Ajmone           
==============================================================================
Copyright © Tristano Ajmone, 2017, MIT License (MIT). Project's home:
- https://github.com/tajmone/pandoc-goodies
The CSS in this template reuses source code taken from the following projects:
- GitHub Markdown CSS: Copyright © Sindre Sorhus, MIT License (MIT):
  https://github.com/sindresorhus/github-markdown-css
- Primer CSS: Copyright © 2016-2017 GitHub Inc., MIT License (MIT):
  http://primercss.io/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The MIT License 
Copyright (c) Tristano Ajmone, 2017 (github.com/tajmone/pandoc-goodies)
Copyright (c) Sindre Sorhus <sindresorhus@gmail.com> (sindresorhus.com)
Copyright (c) 2017 GitHub Inc.
"GitHub Pandoc HTML5 Template" is Copyright (c) Tristano Ajmone, 2017, released
under the MIT License (MIT); it contains readaptations of substantial portions
of the following third party softwares:
(1) "GitHub Markdown CSS", Copyright (c) Sindre Sorhus, MIT License (MIT).
(2) "Primer CSS", Copyright (c) 2016 GitHub Inc., MIT License (MIT).
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
==============================================================================-->
<html>
<head>
  <meta name="generator" content="pandoc" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
  <meta http-equiv="X-UA-Compatible" content="IE=edge" />
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>GridDB 機能リファレンス</title>
  <style type="text/css">
.markdown-body{-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%;color:#24292e;font-family:-apple-system,system-ui,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px;line-height:1.5;word-wrap:break-word;box-sizing:border-box;min-width:200px;max-width:980px;margin:0 auto;padding:45px}.markdown-body a{color:#0366d6;background-color:transparent;text-decoration:none;-webkit-text-decoration-skip:objects}.markdown-body a:active,.markdown-body a:hover{outline-width:0}.markdown-body a:hover{text-decoration:underline}.markdown-body a:not([href]){color:inherit;text-decoration:none}.markdown-body strong{font-weight:600}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{margin-top:24px;margin-bottom:16px;font-weight:600;line-height:1.25}.markdown-body h1{font-size:2em;margin:.67em 0;padding-bottom:.3em;border-bottom:1px solid #eaecef}.markdown-body h2{padding-bottom:.3em;font-size:1.5em;border-bottom:1px solid #eaecef}.markdown-body h3{font-size:1.25em}.markdown-body h4{font-size:1em}.markdown-body h5{font-size:.875em}.markdown-body h6{font-size:.85em;color:#6a737d}.markdown-body img{border-style:none}.markdown-body svg:not(:root){overflow:hidden}.markdown-body hr{box-sizing:content-box;height:.25em;margin:24px 0;padding:0;overflow:hidden;background-color:#e1e4e8;border:0}.markdown-body hr::before{display:table;content:""}.markdown-body hr::after{display:table;clear:both;content:""}.markdown-body input{margin:0;overflow:visible;font:inherit;font-family:inherit;font-size:inherit;line-height:inherit}.markdown-body [type=checkbox]{box-sizing:border-box;padding:0}.markdown-body *{box-sizing:border-box}.markdown-body blockquote{margin:0}.markdown-body ol,.markdown-body ul{padding-left:2em}.markdown-body ol ol,.markdown-body ul ol{list-style-type:lower-roman}.markdown-body ol ol,.markdown-body ol ul,.markdown-body ul ol,.markdown-body ul ul{margin-top:0;margin-bottom:0}.markdown-body ol ol ol,.markdown-body ol ul ol,.markdown-body ul ol ol,.markdown-body ul ul ol{list-style-type:lower-alpha}.markdown-body li>p{margin-top:16px}.markdown-body li+li{margin-top:.25em}.markdown-body dd{margin-left:0}.markdown-body dl{padding:0}.markdown-body dl dt{padding:0;margin-top:16px;font-size:1em;font-style:italic;font-weight:600}.markdown-body dl dd{padding:0 16px;margin-bottom:16px}.markdown-body code{font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace}.markdown-body pre{font:12px SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;word-wrap:normal}.markdown-body blockquote,.markdown-body dl,.markdown-body ol,.markdown-body p,.markdown-body pre,.markdown-body table,.markdown-body ul{margin-top:0;margin-bottom:16px}.markdown-body blockquote{padding:0 1em;color:#6a737d;border-left:.25em solid #dfe2e5}.markdown-body blockquote>:first-child{margin-top:0}.markdown-body blockquote>:last-child{margin-bottom:0}.markdown-body table{display:block;overflow:auto;border-spacing:0;border-collapse:collapse}.markdown-body table th{font-weight:600}.markdown-body table td,.markdown-body table th{padding:6px 13px;border:1px solid #dfe2e5}.markdown-body table tr{background-color:#fff;border-top:1px solid #c6cbd1}.markdown-body table tr:nth-child(2n){background-color:#f6f8fa}.markdown-body figure{text-align:center;margin:1em 0;}.markdown-body img{box-sizing:content-box;background-color:#fff}.markdown-body code{padding:.2em 0;margin:0;font-size:85%;background-color:rgba(27,31,35,.05);border-radius:3px}.markdown-body code::after,.markdown-body code::before{letter-spacing:-.2em;content:"\00a0"}.markdown-body pre>code{padding:0;margin:0;font-size:100%;word-break:normal;white-space:pre;background:0 0;border:0}.markdown-body .highlight{margin-bottom:16px}.markdown-body .highlight pre{margin-bottom:0;word-break:normal}.markdown-body .highlight pre,.markdown-body pre{padding:16px;overflow:auto;font-size:85%;line-height:1.45;background-color:#f6f8fa;border-radius:3px}.markdown-body pre code{display:inline;max-width:auto;padding:0;margin:0;overflow:visible;line-height:inherit;word-wrap:normal;background-color:transparent;border:0}.markdown-body pre code::after,.markdown-body pre code::before{content:normal}.markdown-body .full-commit .btn-outline:not(:disabled):hover{color:#005cc5;border-color:#005cc5}.markdown-body kbd{box-shadow:inset 0 -1px 0 #959da5;display:inline-block;padding:3px 5px;font:11px/10px SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;color:#444d56;vertical-align:middle;background-color:#fcfcfc;border:1px solid #c6cbd1;border-bottom-color:#959da5;border-radius:3px;box-shadow:inset 0 -1px 0 #959da5}.markdown-body :checked+.radio-label{position:relative;z-index:1;border-color:#0366d6}.markdown-body .task-list-item{list-style-type:none}.markdown-body .task-list-item+.task-list-item{margin-top:3px}.markdown-body .task-list-item input{margin:0 .2em .25em -1.6em;vertical-align:middle}.markdown-body::before{display:table;content:""}.markdown-body::after{display:table;clear:both;content:""}.markdown-body>:first-child{margin-top:0!important}.markdown-body>:last-child{margin-bottom:0!important}.Alert,.Error,.Note,.Success,.Warning{padding:11px;margin-bottom:24px;border-style:solid;border-width:1px;border-radius:4px}.Alert p,.Error p,.Note p,.Success p,.Warning p{margin-top:0}.Alert p:last-child,.Error p:last-child,.Note p:last-child,.Success p:last-child,.Warning p:last-child{margin-bottom:0}.Alert{color:#246;background-color:#e2eef9;border-color:#bac6d3}.Warning{color:#4c4a42;background-color:#fff9ea;border-color:#dfd8c2}.Error{color:#911;background-color:#fcdede;border-color:#d2b2b2}.Success{color:#22662c;background-color:#e2f9e5;border-color:#bad3be}.Note{color:#2f363d;background-color:#f6f8fa;border-color:#d5d8da}.Alert h1,.Alert h2,.Alert h3,.Alert h4,.Alert h5,.Alert h6{color:#246;margin-bottom:0}.Warning h1,.Warning h2,.Warning h3,.Warning h4,.Warning h5,.Warning h6{color:#4c4a42;margin-bottom:0}.Error h1,.Error h2,.Error h3,.Error h4,.Error h5,.Error h6{color:#911;margin-bottom:0}.Success h1,.Success h2,.Success h3,.Success h4,.Success h5,.Success h6{color:#22662c;margin-bottom:0}.Note h1,.Note h2,.Note h3,.Note h4,.Note h5,.Note h6{color:#2f363d;margin-bottom:0}.Alert h1:first-child,.Alert h2:first-child,.Alert h3:first-child,.Alert h4:first-child,.Alert h5:first-child,.Alert h6:first-child,.Error h1:first-child,.Error h2:first-child,.Error h3:first-child,.Error h4:first-child,.Error h5:first-child,.Error h6:first-child,.Note h1:first-child,.Note h2:first-child,.Note h3:first-child,.Note h4:first-child,.Note h5:first-child,.Note h6:first-child,.Success h1:first-child,.Success h2:first-child,.Success h3:first-child,.Success h4:first-child,.Success h5:first-child,.Success h6:first-child,.Warning h1:first-child,.Warning h2:first-child,.Warning h3:first-child,.Warning h4:first-child,.Warning h5:first-child,.Warning h6:first-child{margin-top:0}h1.title,p.subtitle{text-align:center}h1.title.followed-by-subtitle{margin-bottom:0}p.subtitle{font-size:1.5em;font-weight:600;line-height:1.25;margin-top:0;margin-bottom:16px;padding-bottom:.3em}div.line-block{white-space:pre-line}
  </style>
  <style type="text/css">
#TOC{ width: 23%; height: 100%; top: 0px; left: 0px; font-size: 70%; position: fixed; overflow: auto; }
#TOC ul { margin: 1pt 0 1pt 1.5em; padding: 0; list-style-type: none; }
#TOC li { margin: 1pt 0; }
#main{ width: 76%; float: right; }
#postamble { display: none; }
.revision { text-align: right; font-size: 8pt; }
@media print { 
#TOC { width:100%; font-size: 100%; position: static; overflow: visible; }
#main { padding: 0px; width:100%; float: none; }
}
  </style>
  <style type="text/css">code{white-space: pre;}</style>
  <style type="text/css">
pre > code.sourceCode { white-space: pre; position: relative; }
pre > code.sourceCode > span { display: inline-block; line-height: 1.25; }
pre > code.sourceCode > span:empty { height: 1.2em; }
code.sourceCode > span { color: inherit; text-decoration: inherit; }
div.sourceCode { margin: 1em 0; }
pre.sourceCode { margin: 0; }
@media screen {
div.sourceCode { overflow: auto; }
}
@media print {
pre > code.sourceCode { white-space: pre-wrap; }
pre > code.sourceCode > span { text-indent: -5em; padding-left: 5em; }
}
pre.numberSource code
  { counter-reset: source-line 0; }
pre.numberSource code > span
  { position: relative; left: -4em; counter-increment: source-line; }
pre.numberSource code > span > a:first-child::before
  { content: counter(source-line);
    position: relative; left: -1em; text-align: right; vertical-align: baseline;
    border: none; display: inline-block;
    -webkit-touch-callout: none; -webkit-user-select: none;
    -khtml-user-select: none; -moz-user-select: none;
    -ms-user-select: none; user-select: none;
    padding: 0 4px; width: 4em;
    color: #aaaaaa;
  }
pre.numberSource { margin-left: 3em; border-left: 1px solid #aaaaaa;  padding-left: 4px; }
div.sourceCode
  {   }
@media screen {
pre > code.sourceCode > span > a:first-child::before { text-decoration: underline; }
}
code span.al { color: #ff0000; font-weight: bold; } /* Alert */
code span.an { color: #60a0b0; font-weight: bold; font-style: italic; } /* Annotation */
code span.at { color: #7d9029; } /* Attribute */
code span.bn { color: #40a070; } /* BaseN */
code span.bu { } /* BuiltIn */
code span.cf { color: #007020; font-weight: bold; } /* ControlFlow */
code span.ch { color: #4070a0; } /* Char */
code span.cn { color: #880000; } /* Constant */
code span.co { color: #60a0b0; font-style: italic; } /* Comment */
code span.cv { color: #60a0b0; font-weight: bold; font-style: italic; } /* CommentVar */
code span.do { color: #ba2121; font-style: italic; } /* Documentation */
code span.dt { color: #902000; } /* DataType */
code span.dv { color: #40a070; } /* DecVal */
code span.er { color: #ff0000; font-weight: bold; } /* Error */
code span.ex { } /* Extension */
code span.fl { color: #40a070; } /* Float */
code span.fu { color: #06287e; } /* Function */
code span.im { } /* Import */
code span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Information */
code span.kw { color: #007020; font-weight: bold; } /* Keyword */
code span.op { color: #666666; } /* Operator */
code span.ot { color: #007020; } /* Other */
code span.pp { color: #bc7a00; } /* Preprocessor */
code span.sc { color: #4070a0; } /* SpecialChar */
code span.ss { color: #bb6688; } /* SpecialString */
code span.st { color: #4070a0; } /* String */
code span.va { color: #19177c; } /* Variable */
code span.vs { color: #4070a0; } /* VerbatimString */
code span.wa { color: #60a0b0; font-weight: bold; font-style: italic; } /* Warning */
  </style>
  <!--[if lt IE 9]>
    <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
  <![endif]-->
</head>
<body>
<div id="main">
<article class="markdown-body">
<header>
<h1 class="title">GridDB 機能リファレンス</h1>
</header>
<p class="revision">Revision: CE-20200203</p>
<hr>
<nav id="TOC">
<h1 class="toc-title">Table of Contents</h1>
<ul>
<li><a href="#はじめに"><span class="toc-section-number">1</span> はじめに</a>
<ul>
<li><a href="#本書の目的と構成"><span class="toc-section-number">1.1</span> 本書の目的と構成</a></li>
</ul></li>
<li><a href="#griddbとは"><span class="toc-section-number">2</span> GridDBとは</a>
<ul>
<li><a href="#griddbの特徴"><span class="toc-section-number">2.1</span> GridDBの特徴</a>
<ul>
<li><a href="#大容量データvolume"><span class="toc-section-number">2.1.1</span> 大容量データ(Volume)</a></li>
<li><a href="#さまざまなデータvariety"><span class="toc-section-number">2.1.2</span> さまざまなデータ(Variety)</a></li>
<li><a href="#高速処理velocity"><span class="toc-section-number">2.1.3</span> 高速処理(Velocity)</a>
<ul>
<li><a href="#できるだけメモリ上で処理をする"><span class="toc-section-number">2.1.3.1</span> できるだけメモリ上で処理をする</a></li>
<li><a href="#オーバヘッドを減らす"><span class="toc-section-number">2.1.3.2</span> オーバヘッドを減らす</a></li>
<li><a href="#並列に処理をする"><span class="toc-section-number">2.1.3.3</span> 並列に処理をする</a></li>
</ul></li>
<li><a href="#信頼性可用性"><span class="toc-section-number">2.1.4</span> 信頼性／可用性</a></li>
</ul></li>
</ul></li>
<li><a href="#用語一覧"><span class="toc-section-number">3</span> 用語一覧</a></li>
<li><a href="#griddbの仕組み"><span class="toc-section-number">4</span> GridDBの仕組み</a>
<ul>
<li><a href="#クラスタの構成"><span class="toc-section-number">4.1</span> クラスタの構成</a>
<ul>
<li><a href="#ノードのステータス"><span class="toc-section-number">4.1.1</span> ノードのステータス</a></li>
<li><a href="#クラスタのステータス"><span class="toc-section-number">4.1.2</span> クラスタのステータス</a></li>
<li><a href="#パーティションのステータス"><span class="toc-section-number">4.1.3</span> パーティションのステータス</a></li>
</ul></li>
<li><a href="#クラスタ構成方式"><span class="toc-section-number">4.2</span> クラスタ構成方式</a>
<ul>
<li><a href="#クラスタ構成方式の設定"><span class="toc-section-number">4.2.1</span> クラスタ構成方式の設定</a>
<ul>
<li><a href="#固定リスト方式"><span class="toc-section-number">4.2.1.1</span> 固定リスト方式</a></li>
<li><a href="#プロバイダ方式"><span class="toc-section-number">4.2.1.2</span> プロバイダ方式</a></li>
</ul></li>
</ul></li>
</ul></li>
<li><a href="#データモデル"><span class="toc-section-number">5</span> データモデル</a>
<ul>
<li><a href="#コンテナ"><span class="toc-section-number">5.1</span> コンテナ</a>
<ul>
<li><a href="#種別"><span class="toc-section-number">5.1.1</span> 種別</a></li>
<li><a href="#データ型"><span class="toc-section-number">5.1.2</span> データ型</a>
<ul>
<li><a href="#基本型"><span class="toc-section-number">5.1.2.1</span> 基本型</a></li>
<li><a href="#複合型"><span class="toc-section-number">5.1.2.2</span> 複合型</a></li>
</ul></li>
<li><a href="#主キー"><span class="toc-section-number">5.1.3</span> 主キー</a></li>
</ul></li>
</ul></li>
<li><a href="#データベース機能"><span class="toc-section-number">6</span> データベース機能</a>
<ul>
<li><a href="#リソースの管理"><span class="toc-section-number">6.1</span> リソースの管理</a></li>
<li><a href="#データアクセス機能"><span class="toc-section-number">6.2</span> データアクセス機能</a>
<ul>
<li><a href="#tql"><span class="toc-section-number">6.2.1</span> TQL</a></li>
<li><a href="#複数コンテナへの一括処理機能"><span class="toc-section-number">6.2.2</span> 複数コンテナへの一括処理機能</a></li>
</ul></li>
<li><a href="#索引機能"><span class="toc-section-number">6.3</span> 索引機能</a></li>
<li><a href="#時系列データ特有の機能"><span class="toc-section-number">6.4</span> 時系列データ特有の機能</a>
<ul>
<li><a href="#圧縮機能"><span class="toc-section-number">6.4.1</span> 圧縮機能</a>
<ul>
<li><a href="#誤差あり間引き圧縮hi"><span class="toc-section-number">6.4.1.1</span> 誤差あり間引き圧縮(HI)</a></li>
<li><a href="#誤差なし間引き圧縮ss"><span class="toc-section-number">6.4.1.2</span> 誤差なし間引き圧縮(SS)</a></li>
</ul></li>
<li><a href="#tqlの演算機能"><span class="toc-section-number">6.4.2</span> TQLの演算機能</a>
<ul>
<li><a href="#集計演算"><span class="toc-section-number">6.4.2.1</span> 集計演算</a></li>
<li><a href="#選択補間演算"><span class="toc-section-number">6.4.2.2</span> 選択・補間演算</a></li>
</ul></li>
<li><a href="#期限解放機能"><span class="toc-section-number">6.4.3</span> 期限解放機能</a>
<ul>
<li><a href="#期限解放の種類"><span class="toc-section-number">6.4.3.1</span> 期限解放の種類</a></li>
</ul></li>
</ul></li>
<li><a href="#トランザクション機能"><span class="toc-section-number">6.5</span> トランザクション機能</a>
<ul>
<li><a href="#トランザクションの開始と終了"><span class="toc-section-number">6.5.1</span> トランザクションの開始と終了</a></li>
<li><a href="#トランザクションの一貫性レベル"><span class="toc-section-number">6.5.2</span> トランザクションの一貫性レベル</a></li>
<li><a href="#トランザクションの隔離レベル"><span class="toc-section-number">6.5.3</span> トランザクションの隔離レベル</a></li>
<li><a href="#mvcc"><span class="toc-section-number">6.5.4</span> MVCC</a></li>
<li><a href="#ロック"><span class="toc-section-number">6.5.5</span> ロック</a>
<ul>
<li><a href="#ロックの粒度"><span class="toc-section-number">6.5.5.1</span> ロックの粒度</a></li>
<li><a href="#データベース操作によるロック範囲"><span class="toc-section-number">6.5.5.2</span> データベース操作によるロック範囲</a></li>
</ul></li>
<li><a href="#データ永続化"><span class="toc-section-number">6.5.6</span> データ永続化</a></li>
<li><a href="#タイムアウト処理"><span class="toc-section-number">6.5.7</span> タイムアウト処理</a>
<ul>
<li><a href="#nosql-ifのタイムアウト処理"><span class="toc-section-number">6.5.7.1</span> NoSQL I/Fのタイムアウト処理</a></li>
</ul></li>
</ul></li>
<li><a href="#レプリケーション機能"><span class="toc-section-number">6.6</span> レプリケーション機能</a></li>
<li><a href="#アフィニティ機能"><span class="toc-section-number">6.7</span> アフィニティ機能</a>
<ul>
<li><a href="#データアフィニティ機能"><span class="toc-section-number">6.7.1</span> データアフィニティ機能</a></li>
<li><a href="#ノードアフィニティ機能"><span class="toc-section-number">6.7.2</span> ノードアフィニティ機能</a></li>
</ul></li>
<li><a href="#トリガ機能"><span class="toc-section-number">6.8</span> トリガ機能</a></li>
<li><a href="#コンテナテーブルの定義変更"><span class="toc-section-number">6.9</span> コンテナ(テーブル)の定義変更</a>
<ul>
<li><a href="#カラム追加"><span class="toc-section-number">6.9.1</span> カラム追加</a></li>
<li><a href="#カラム削除"><span class="toc-section-number">6.9.2</span> カラム削除</a></li>
</ul></li>
<li><a href="#データベース圧縮解放機能"><span class="toc-section-number">6.10</span> データベース圧縮/解放機能</a>
<ul>
<li><a href="#データブロック圧縮"><span class="toc-section-number">6.10.1</span> データブロック圧縮</a></li>
<li><a href="#データブロック未使用領域解放"><span class="toc-section-number">6.10.2</span> データブロック未使用領域解放</a></li>
</ul></li>
</ul></li>
<li><a href="#パラメータ"><span class="toc-section-number">7</span> パラメータ</a>
<ul>
<li><a href="#クラスタ定義ファイルgs_clusterjson"><span class="toc-section-number">7.1</span> クラスタ定義ファイル（gs_cluster.json)</a></li>
<li><a href="#ノード定義ファイルgs_nodejson"><span class="toc-section-number">7.2</span> ノード定義ファイル(gs_node.json)</a></li>
</ul></li>
<li><a href="#システムの制限値"><span class="toc-section-number">8</span> システムの制限値</a>
<ul>
<li><a href="#数値に関する制限"><span class="toc-section-number">8.1</span> 数値に関する制限</a></li>
<li><a href="#ネーミングに関する制限"><span class="toc-section-number">8.2</span> ネーミングに関する制限</a></li>
</ul></li>
</ul>
</nav>
<hr>
<h1 data-number="1" id="はじめに" data-number="1"><span class="header-section-number">1</span> はじめに</h1>
<h2 data-number="1.1" id="本書の目的と構成" data-number="1.1"><span class="header-section-number">1.1</span> 本書の目的と構成</h2>
<p><strong>本書では、GridDBの機能について説明します。</strong>本書は、以下のような構成となっています。</p>
<ul>
<li>GridDBとは
<ul>
<li>GridDBの特長やGridDBの適用例を説明します。</li>
</ul></li>
<li>GridDBの仕組み
<ul>
<li>GridDBのクラスタ動作の仕組みについて説明します。</li>
</ul></li>
<li>GridDBのデータモデル
<ul>
<li>GridDBのデータモデルについて説明します。</li>
</ul></li>
<li>GridDBが提供する機能
<ul>
<li>GridDBが提供するデータ管理の機能について説明します。</li>
</ul></li>
<li>パラメータ
<ul>
<li>GridDBの動作を制御するパラメータについて説明します。</li>
</ul></li>
</ul>
<h1 data-number="2" id="griddbとは" data-number="2"><span class="header-section-number">2</span> GridDBとは</h1>
<p>GridDBは、キーと複数の値からなるデータ(ロウと呼ばれる)の集合を管理する、分散NoSQL型データベースです。 データをすべてメモリに配置するインメモリデータベースとしての構成に加え、ディスク(SSDも含む)とメモリの利用を併用したハイブリッド構成も取れます。ハイブリッド構成を用いることで、小規模、小メモリシステムでも活用可能です。</p>
<p>GridDBはビッグデータソリューションで必要となる３つのV(Volume,Variety,Velocity)に加え、データの信頼性／可用性を備えています。また、自律的なノード監視と負荷バランシング機能により、クラスタ運用の省力化が実現できます。</p>
<p><a id="griddb_features"></a></p>
<h2 data-number="2.1" id="griddbの特徴" data-number="2.1"><span class="header-section-number">2.1</span> GridDBの特徴</h2>
<h3 data-number="2.1.1" id="大容量データvolume" data-number="2.1.1"><span class="header-section-number">2.1.1</span> 大容量データ(Volume)</h3>
<p>システムの規模拡大とともに扱うデータの容量は増大し、大容量データを素早く処理するためにはシステムの拡張が必要になります。</p>
<p>システムの拡張のアプローチには、大きく分けてスケールアップ(垂直スケーラビリティ）とスケールアウト(水平スケーラビリティ）の２つのアプローチがあります。</p>
<ul>
<li><p>スケールアップ（垂直スケーラビリティ）とは</p>
<p>動作するマシンへのメモリ追加、ディスクのSSD化、プロセッサの追加などの方法でシステムを増強するアプローチです。一般的に、１つ１つの処理時間を短縮してシステムを高速化するという効果があります。その反面、複数台マシンを用いたクラスタ運用ではないため、スケールアップ時には一旦ノードを停止する必要があり、障害発生時には障害回復に時間がかかるなどの欠点があります。</p></li>
<li><p>スケールアウト（水平スケーラビリティ）とは</p>
<p>システムを構成するノードの台数を増やして処理能力を向上させるアプローチです。一般的に、複数のノードを連携して動作させることになるため、メンテナンスや障害発生時でもサービスを完全に停止させる必要がない点が利点となります。その反面、ノード台数が増えるために運用管理の手間が増大するなどの欠点があります。並列度の高い処理を行なうのに向いたアーキテクチャです。</p></li>
</ul>
<p>GridDBでは、動作するノードをスケールアップしてシステム増強する方法に加え、システムに新たなノードを追加し、稼働するクラスタに組み込むスケールアウトでシステムを拡張することもできます。</p>
<p>GridDBは、インメモリ処理データベースとしてもスケールアウトモデルで大容量化が可能です。GridDBでは、複数ノードで構成されるクラスタ内のノードにデータを分散配置します。複数ノードのメモリを１つの大きなメモリ空間として利用することで、大規模なメモリデータベースを提供できます。</p>
<p>また、メモリの利用だけでなく、ディスクを併用したハイブリッド構成のデータ管理も可能であるため、単体のノードで動作させた場合も、メモリサイズを超えたデータを保持して、アクセスができます。メモリサイズに制限されない大容量化も実現できます。</p>
<figure>
<img src="img/feature_disk_and_memory.png" alt="インメモリ／ディスクの併用" width="450"/>
<figcaption>インメモリ／ディスクの併用</figcaption>
</figure>

<p>スケールアウトでのシステム拡張は、オンラインで行うことができます。そのため、運用中のシステムを停止することなく、システムの成長とともに増大するデータに対応できます。</p>
<p>スケールアウトでシステムに追加したノードには、システムの負荷に応じて適切にデータが配置されます。GridDBが負荷バランスを最適化するため、運用管理者がデータ配置を気にする必要はありません。このような運用を自動化する仕組みが組み込まれており、運用も容易です。</p>
<figure>
<img src="img/feature_scale_up.png" alt="スケールアウトモデル" width="600"/>
<figcaption>スケールアウトモデル</figcaption>
</figure>

<h3 data-number="2.1.2" id="さまざまなデータvariety" data-number="2.1.2"><span class="header-section-number">2.1.2</span> さまざまなデータ(Variety)</h3>
<p>GridDBのデータは、Key-Valueを発展させたKey-Container型のデータモデルです。コンテナというRDBのテーブルに相当する器にデータを格納します。 （コンテナをRDBのテーブルとして考えるとわかりやすいです。）</p>
<p>GridDBのデータアクセスでは、Key-Valueデータベース構造のため、Keyで絞り込みができるモデルが最も高速に処理できます。管理する実体に対応して、キーとなるコンテナを用意するという設計が必要です。</p>
<figure>
<img src="img/feature_data_model.png" alt="データモデル" width="500"/>
<figcaption>データモデル</figcaption>
</figure>

<p>コンテナには、センサ等の時々刻々発生する時間と値のペアになった大量の時系列のデータを扱うのに適したコンテナ(時系列コンテナ）に加え、位置情報などの空間データを登録し、空間固有の演算（空間の交差）を行うこともできます。配列型のデータやBLOBなどの非定型なデータにも対応しているため、さまざまなデータを扱うことができます。</p>
<p>時系列コンテナには、特有の圧縮機能や保持期限の切れたデータの解放機能などを提供しており、大量に発生するデータの管理に適しています。</p>
<h3 data-number="2.1.3" id="高速処理velocity" data-number="2.1.3"><span class="header-section-number">2.1.3</span> 高速処理(Velocity)</h3>
<p>GridDBには、さまざまなアーキテクチャ上の工夫が組み込まれ、高速化を実現しています。</p>
<h4 data-number="2.1.3.1" id="できるだけメモリ上で処理をする" data-number="2.1.3.1"><span class="header-section-number">2.1.3.1</span> できるだけメモリ上で処理をする</h4>
<p>全てのデータがメモリに配置されてインメモリで動作するシステムの場合、ディスクへのアクセスのオーバヘッドをあまり気にする必要がありません。しかし、メモリ上に保持できないほどの大量のデータを処理するためには、アプリケーションがアクセスするデータを局所化して、ディスクに配置されたデータへのアクセスをできるだけ少なくする必要があります。</p>
<p>GridDBでは、アプリケーションからのデータアクセスを局所化するために、関連のあるデータをできるだけ同じブロックに配置する機能を提供します。データにヒント情報を与えることで、ヒントに従ったデータブロックにデータを集約し、データアクセス時のメモリ内ヒット率を高め、データアクセス時間を高速化します。アプリケーションでのアクセス頻度やアクセスパターンに応じて、メモリ集約のヒントを設定することで、限られたメモリ領域を有効活用して動作させることができます（アフィニティ機能）。</p>
<h4 data-number="2.1.3.2" id="オーバヘッドを減らす" data-number="2.1.3.2"><span class="header-section-number">2.1.3.2</span> オーバヘッドを減らす</h4>
<p>データベースに対して並列にアクセスする時のロックやラッチなどによる、データベースの実行処理待ちとなる時間をできるだけ少なくするために、GridDBでは、CPUコア・スレッドごとに占有するメモリとデータベースファイルを割り当て、排他、同期処理の待ちをなくしています。</p>
<figure>
<img src="img/feature_architecture.png" alt="アーキテクチャ" width="500"/>
<figcaption>アーキテクチャ</figcaption>
</figure>

<p>また、GridDBでは、クライアントライブラリ側で初回アクセス時にデータ配置をキャッシュすることで、クライアントとノード間は直接アクセス可能です。データ配置やクラスタの動作状況を管理するマスタノードを介さず、直接目的とするデータにアクセスできるので、マスタノードへのアクセス集中や、通信コストを大幅に削減できます。</p>
<figure>
<img src="img/feature_client_access.png" alt="クライアントからのアクセス" width="500"/>
<figcaption>クライアントからのアクセス</figcaption>
</figure>

<h4 data-number="2.1.3.3" id="並列に処理をする" data-number="2.1.3.3"><span class="header-section-number">2.1.3.3</span> 並列に処理をする</h4>
<p>GridDBでは、1つの巨大なデータを複数ノードに分散配置（パーティショニング）したノード間、およびノード内での並列処理と、少ないリソースで多くの要求を処理できるイベント駆動エンジンで、高速化を実現しています。</p>
<h3 data-number="2.1.4" id="信頼性可用性" data-number="2.1.4"><span class="header-section-number">2.1.4</span> 信頼性／可用性</h3>
<p>クラスタ内ではデータを複製して、複数のノード上にデータ(レプリカ)を多重配置しています。レプリカの中で、マスタのデータをオーナ、複製したデータをバックアップと呼びます。クラスタを構成するいずれかのノードに障害が発生した場合でも、レプリカを使用することで処理を継続できます。ノード障害発生後のデータ再配置もシステムが自動的に行うため(自律的データ配置）、特別な運用操作は不要です。障害対象のノードに配置されていたデータはレプリカから復旧され、自動的に設定されたレプリカ数となるようにデータは再配置されます。</p>
<p>レプリカは、可用性の要求に応じて2重化、3重化など多重度の設定ができます。</p>
<p>各ノードはディスクを使用してデータ更新情報の永続化を行っています。クラスタシステムに障害が発生しても、ディスクに問題がなければ、それまで登録・更新したデータを失わずに復元することができます。</p>
<p>また、クライアントでもデータ配置管理情報のキャッシュを保有しているため、ノードの障害を検知すると自動的にフェイルオーバーし、レプリカを用いたデータアクセスを継続できます。</p>
<figure>
<img src="img/feature_durability.png" alt="高可用性" width="500"/>
<figcaption>高可用性</figcaption>
</figure>

<h1 data-number="3" id="用語一覧" data-number="3"><span class="header-section-number">3</span> 用語一覧</h1>
<p>GridDBで利用する用語を一覧で解説します。</p>
<table>
<thead>
<tr class="header">
<th>用語</th>
<th>意味</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>ノード</td>
<td>GridDBでデータ管理を行う個々のサーバプロセスを指します。</td>
</tr>
<tr class="even">
<td>クラスタ</td>
<td>一体となってデータ管理を行う、1つ、もしくは複数のノードの集合を指します。</td>
</tr>
<tr class="odd">
<td>マスタノード</td>
<td>クラスタ管理処理を行うノードです。</td>
</tr>
<tr class="even">
<td>フォロワノード</td>
<td>クラスタに参加している、マスタノード以外のノードです。</td>
</tr>
<tr class="odd">
<td>構成ノード数</td>
<td>GridDBクラスタを構成するノード数を指定します。GridDBが初回に起動する際に、クラスタが成立する閾値として用いられます。（構成ノード数のノードがクラスタに参加することでクラスタサービスが開始されます。）</td>
</tr>
<tr class="even">
<td>有効ノード数</td>
<td>GridDBクラスタを構成するノードの内、クラスタに組み込まれた稼働中のノードの数です。</td>
</tr>
<tr class="odd">
<td>ブロック</td>
<td>ブロックとは、ディスクへのデータ永続化処理（以降、チェックポイントと呼びます）のデータ単位であり、GridDBの物理的なデータ管理の最小単位です。ブロックには複数のコンテナのデータが配置されます。ブロックサイズは、GridDBの初期起動前に定義ファイル（クラスタ定義ファイル）で設定します。</td>
</tr>
<tr class="even">
<td>パーティション</td>
<td>コンテナを配置するデータ管理の単位です。クラスタ間でのデータ配置の最小単位であり、ノード間の負荷バランスを調整するため(リバランス）や、障害発生時のデータ多重化（レプリカ）管理のためのデータ移動や複製の単位です。</td>
</tr>
<tr class="odd">
<td>パーティショングループ</td>
<td>複数のパーティションをまとめたグループであり、データをディスクに永続化する際のファイルシステム上のデータファイルに相当します。1つのパーティショングループに1つのチェックポイントファイルが対応します。パーティショングループは、ノード定義ファイルの並列度(/dataStore/concurrency)の数だけ作成されます。</td>
</tr>
<tr class="even">
<td>ロウ</td>
<td>コンテナ(テーブル)に登録される1行のデータを指します。コンテナ(テーブル)には複数のロウが登録されます。ロウは、コンテナ(テーブル)のスキーマ定義に対応したカラムの値から構成されます。</td>
</tr>
<tr class="odd">
<td>コンテナ(テーブル)</td>
<td>ロウの集合を管理する入れ物です。コンテナには、コレクションと時系列コンテナの２種類のデータタイプが存在します。</td>
</tr>
<tr class="even">
<td>コレクション(テーブル)</td>
<td>一般の型のキーを持つロウを管理するコンテナ(テーブル)の１種です。</td>
</tr>
<tr class="odd">
<td>時系列コンテナ(時系列テーブル)</td>
<td>時刻型のキーを持つロウを管理するコンテナ(テーブル)の１種です。時系列のデータを扱う専用の機能を持ちます。</td>
</tr>
<tr class="even">
<td>データベースファイル</td>
<td>クラスタを構成するノードの保有するデータをディスクやSSDに書き込み、永続化したファイル群です。データベースファイルは、定期的にメモリ上のデータベースが書き込まれるチェックポイントファイルと、データ更新の都度保存されるトランザクションログファイルを総称します。</td>
</tr>
<tr class="odd">
<td>チェックポイントファイル</td>
<td>パーティショングループがディスクに書き込まれたファイルです。 ノード定義ファイルのサイクル（/checkpoint/checkpointInterval）でメモリ上の更新情報が反映されます。</td>
</tr>
<tr class="even">
<td>トランザクションログファイル</td>
<td>トランザクションの更新情報がログとして逐次保存されるファイルです。</td>
</tr>
<tr class="odd">
<td>LSN（Log Sequence Number)</td>
<td>パーティションごとに割り当てられる、トランザクションでの更新時の更新ログシーケンス番号です。クラスタ構成のマスタノードは、各ノードが保持している全パーティションのLSNのうちの最大数（MAXLSN)を保持しています。</td>
</tr>
<tr class="even">
<td>レプリカ</td>
<td>複数のノードにパーティションを多重化配置することを指します。レプリカには更新されるマスタデータであるオーナと参照に利用されるバックアップがあります。</td>
</tr>
<tr class="odd">
<td>オーナノード</td>
<td>パーティション内のコンテナに対して更新操作ができるノードです。複製されたコンテナのうち、マスタとなるコンテナを記録しているノードです。</td>
</tr>
<tr class="even">
<td>バックアップノード</td>
<td>複製されたコンテナのうち、バックアップのためのデータを記録しているノードです。</td>
</tr>
<tr class="odd">
<td>定義ファイル</td>
<td>クラスタを構成する際のパラメータファイル（gs_cluster.json：以降クラスタ定義ファイルと呼ぶ）とクラスタ内でのノードの動作やリソースを設定するパラメータファイル（gs_node.json：以降ノード定義ファイルと呼ぶ）の２つがあります。また、ユーザ定義ファイルもあります。</td>
</tr>
<tr class="even">
<td>イベントログファイル</td>
<td>GridDBサーバのイベントログが保管されるファイルです。エラーや警告などのメッセージが含まれます。</td>
</tr>
<tr class="odd">
<td>ユーザ定義ファイル</td>
<td>ユーザが登録されるファイルです。初期インストールではadminが登録されています。</td>
</tr>
<tr class="even">
<td>クラスタデータベース</td>
<td>GridDBのクラスタシステムでアクセスできるデータベース全体を総称します。</td>
</tr>
<tr class="odd">
<td>データベース</td>
<td>クラスタデータベースに作成される、論理的なデータ管理の単位です。クラスタデータベース内にデフォルトではpublicというデータベースが作成されています。</td>
</tr>
<tr class="even">
<td>フェイルオーバ―</td>
<td>稼働中のクラスタに障害が発生した際に、バックアップノードがその機能を自動的に引き継ぎ、処理を続行する仕組みです。</td>
</tr>
<tr class="odd">
<td>クライアントフェイルオーバー</td>
<td>稼働中のクラスタに障害が発生した際、クライアント側のAPIで障害時のリトライ処理としてバックアップノードに自動的に接続し直し、処理を続行する仕組みです。</td>
</tr>
<tr class="even">
<td>データアフィニティ</td>
<td>関連の強いコンテナのデータを同じブロックに配置し、データアクセスの局所化を図ることでメモリヒット率を高めるための機能です。</td>
</tr>
<tr class="odd">
<td>ノードアフィニティ</td>
<td>関連の強いコンテナを同じノードに配置し、データアクセス時のネットワーク負荷を減少させるための機能です。</td>
</tr>
</tbody>
</table>
<h1 data-number="4" id="griddbの仕組み" data-number="4"><span class="header-section-number">4</span> GridDBの仕組み</h1>
<p>GridDBのクラスタ動作のしくみやデータモデルについて説明します。</p>
<h2 data-number="4.1" id="クラスタの構成" data-number="4.1"><span class="header-section-number">4.1</span> クラスタの構成</h2>
<p>GridDBは複数ノードで構成されるクラスタで動作します。アプリケーションシステムからデータベースにアクセスするにはノードが起動されており、かつクラスタが構成(クラスタサービスが実行)されている必要があります。</p>
<p>クラスタは、ユーザが指定した構成ノード数のノードがクラスタへ参加することで構成され、クラスタサービスが開始されます。構成ノード数のノードがクラスタに参加するまでクラスタサービスは開始されず、アプリケーションからはアクセスできません。</p>
<p>ノード1台で動作させる場合にも、クラスタを構成する必要があります。この場合構成ノード数を1台でクラスタを構成することになります。ノード1台で動作させる構成をシングル構成と呼びます。</p>
<figure>
<img src="img/arc_clusterNameCount.png" alt="クラスタ名と構成ノード数" width="500"/>
<figcaption>クラスタ名と構成ノード数</figcaption>
</figure>

<p>ネットワーク上にあるGridDBの多数のノードを用いて、正しく（意図したノードを用いて）クラスタが構成できるよう、クラスタ名を使って複数のクラスタを区別します。これにより、同じネットワーク上に複数のGridDBクラスタが構成できます。クラスタは、クラスタ名、構成ノード数、接続方式の設定が等しいノードで構成されます。クラスタ名は、クラスタを構成するノード毎に保有するクラスタ定義ファイルに設定するとともに、クラスタ構成する際のパラメータでも指定します。</p>
<p>マルチキャストを用いてクラスタを構成する方式をマルチキャスト方式と呼びます。クラスタ構成方式については、<a href="#cluster_configuration_methods">クラスタ構成方式</a>を参照してください。</p>
<p>以下にクラスタ構成の操作の流れを示します。</p>
<figure>
  <img src="img/arc_clusterConfigration.png" alt="クラスタ構成の動作" width="600"/>
  <figcaption>クラスタ構成の動作</figcaption>
</figure>

<p>ノードの起動、クラスタの構成には、gs_startnode/gs_joinclusterコマンドを用います。また、OS起動と同時にノードを起動し、クラスタを構成するサービス制御機能もあります。</p>
<p>クラスタを構成するには、クラスタに参加させるノードの数（構成ノード数）とクラスタ名をすべての参加ノードで一致させる必要があります。</p>
<p>クラスタサービスは、クラスタでの運用開始後に構成するノードに障害がありクラスタからノードが切り離された場合でも、過半数のノードが参加している限りサービスは継続します。</p>
<p>過半数以上のノードさえ動作していればクラスタ運用は継続できるので、クラスタ運用中にメンテナンス等のために、オンラインでノード切り離したり、メンテナンス完了後にノードを組込む操作ができます。さらには、システムを増強するためにノードを追加することもオンラインでできます。</p>
<p>クラスタ内部の通信を行うネットワークとクライアント通信専用のネットワークを分離させることが可能です。</p>
<h3 data-number="4.1.1" id="ノードのステータス" data-number="4.1.1"><span class="header-section-number">4.1.1</span> ノードのステータス</h3>
<p>ノードには、ノードの状態を表す複数の種類のステータスがあります。ユーザのコマンド実行やノードの内部処理によってステータスが遷移します。<a href="#status_of_cluster">クラスタのステータス</a>は、クラスタに属する複数のノードのノードステータスによって決まります。</p>
<p>ノードステータスの種類と遷移、確認方法を説明します。</p>
<ul>
<li><p>ノードステータスの種類</p>
<table>
<thead>
<tr class="header">
<th>ノードステータス</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>STOP</td>
<td>ノードでGridDBサーバが起動されていない状態です。</td>
</tr>
<tr class="even">
<td>STARTING</td>
<td>ノードでGridDBサーバが起動処理中の状態です。前回の運転状態に応じて、データベースのリカバリ処理などの起動時の処理が行われます。クライアントからアクセスできるのは、gs_statコマンドでのシステムの状態確認のみです。アプリケーションからのアクセスはできません。</td>
</tr>
<tr class="odd">
<td>STARTED</td>
<td>ノードでGridDBサーバが起動されている状態です。ただし、クラスタには参加していないため、引き続きアプリケーションからのアクセスはできません。クラスタを構成するには、gs_joinclusterのクラスタ操作コマンドでクラスタへの参加を指示します。</td>
</tr>
<tr class="even">
<td>WAIT</td>
<td>クラスタ構成待ちの状態です。ノードはクラスタへの参加を通知しているが、構成ノード数のノードが足りておらず、ノード数が構成ノード数になるまで待ち状態となります。また、クラスタを構成するノードが過半数以下になり、クラスタのサービスが停止した際のノード状態もWAIT状態になります。</td>
</tr>
<tr class="odd">
<td>SERVICING</td>
<td>クラスタが構成されており、アプリケーションからのアクセスが可能な状態です。ただし、ノード停止時の障害後の再起動などでパーティションのクラスタ間での同期処理が発生した場合、アクセスが遅延することがあります。</td>
</tr>
<tr class="even">
<td>STOPPING</td>
<td>ノードを停止指示後、停止するまでの中間ステータスです。</td>
</tr>
<tr class="odd">
<td>ABNORMAL</td>
<td>SERVICING状態もしくは、状態遷移の途中でノードがエラーを検出した際のステータスです。ABNORMAL状態となったノードは、自動的にクラスタから切り離されます。システムの動作情報を採取してから、ABNORMAL状態のノードを強制停止・再起動する必要があります。再起動することで、リカバリ処理が自動的に行われます。</td>
</tr>
</tbody>
</table></li>
<li><p>ノードステータスの遷移</p>
<figure>
  <img src="img/arc_NodeStatus.png" alt="ノードステータス" width="600"/>
  <figcaption>ノードステータス</figcaption>
</figure>

<table>
<thead>
<tr class="header">
<th>ステータス遷移</th>
<th>状態遷移事象</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>　　 ①</td>
<td>コマンド実行</td>
<td>ノード起動(gs_startnodeコマンドのコマンド実行)</td>
</tr>
<tr class="even">
<td>　　 ②</td>
<td>システム</td>
<td>リカバリ処理やデータベースファイルのロードが完了すると、状態は自動遷移</td>
</tr>
<tr class="odd">
<td>　　 ③</td>
<td>コマンド実行</td>
<td>クラスタ参加(gs_joincluster/gs_appendclusterコマンドなどのコマンド実行)</td>
</tr>
<tr class="even">
<td>　　 ④</td>
<td>システム</td>
<td>構成ノード数のノードがクラスタに参加すると状態は自動遷移</td>
</tr>
<tr class="odd">
<td>　　 ⑤</td>
<td>システム</td>
<td>クラスタを構成する他のノードが障害等によりサービスから切り離され、構成ノード数が設定値の過半数を下回った時に、状態が自動遷移</td>
</tr>
<tr class="even">
<td>　　 ⑥</td>
<td>コマンド実行</td>
<td>ノードをクラスタから切り離す(gs_leaveclusterコマンドのコマンド実行)</td>
</tr>
<tr class="odd">
<td>　　 ⑦</td>
<td>コマンド実行</td>
<td>ノードをクラスタから切り離す(gs_leavecluster/gs_stopclusterコマンドのコマンド実行)</td>
</tr>
<tr class="even">
<td>　　 ⑧</td>
<td>コマンド実行</td>
<td>ノード停止(gs_stopnodeコマンドのコマンド実行)</td>
</tr>
<tr class="odd">
<td>　　 ⑨</td>
<td>システム</td>
<td>終了処理が完了次第、サーバプロセスを停止</td>
</tr>
<tr class="even">
<td>　　 ⑩</td>
<td>システム</td>
<td>システム障害により切り離された状態。この状態では一度ノードを強制的に停止する必要がある。</td>
</tr>
</tbody>
</table></li>
<li><p>ノードステータスの確認方法</p>
<p>ノードステータスは、ノードの稼働状況とノードの役割の2つの状態の組合せによって決まります。ノードの稼働状況とノードの役割は、gs_statコマンドを実行した結果のjson形式のデータから確認できます。（ノードの稼働状況：/cluster/nodeStatusの値、ノードの役割：/cluster/clusterStatusの値)</p>
<p>ノードステータスと、ノードの稼働状況とノードの役割の2つの状態の組合せを以下に示します。</p>
<table>
<thead>
<tr class="header">
<th>ノードステータス</th>
<th>ノードの稼働状況<br>(/cluster/nodeStatus)</th>
<th>ノードの役割<br>(/cluster/clusterStatus)</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>STOP</td>
<td>－(gs_statの接続エラー)</td>
<td>－(gs_statの接続エラー)</td>
</tr>
<tr class="even">
<td>STARTING</td>
<td>INACTIVE</td>
<td>SUB_CLUSTER</td>
</tr>
<tr class="odd">
<td>STARTED</td>
<td>INACTIVE</td>
<td>SUB_CLUSTER</td>
</tr>
<tr class="even">
<td>WAIT</td>
<td>ACTIVE</td>
<td>SUB_CLUSTER</td>
</tr>
<tr class="odd">
<td>SERVICING</td>
<td>ACTIVE</td>
<td>MASTERまたはFOLLOWER</td>
</tr>
<tr class="even">
<td>STOPPING</td>
<td>NORMAL_SHUTDOWN</td>
<td>SUB_CLUSTER</td>
</tr>
<tr class="odd">
<td>ABNORMAL</td>
<td>ABNORMAL</td>
<td>SUB_CLUSTER</td>
</tr>
</tbody>
</table>
<ul>
<li><p>ノードの稼働状況</p>
<p>ノードの稼働状況を表します。gs_statコマンドの/cluster/nodeStatusの値で確認できます。</p>
<table>
<thead>
<tr class="header">
<th>ノードの稼働状況</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>ACTIVE</td>
<td>アクティブ状態</td>
</tr>
<tr class="even">
<td>ACTIVATING</td>
<td>アクティブ状態に遷移中</td>
</tr>
<tr class="odd">
<td>INACTIVE</td>
<td>非アクティブ状態</td>
</tr>
<tr class="even">
<td>DEACTIVATING</td>
<td>非アクティブ状態に遷移中</td>
</tr>
<tr class="odd">
<td>NORMAL_SHUTDOWN</td>
<td>シャットダウン処理中</td>
</tr>
<tr class="even">
<td>ABNORMAL</td>
<td>異常状態</td>
</tr>
</tbody>
</table></li>
<li><p>ノードの役割</p>
<p>ノードの役割を表します。gs_statコマンドの/cluster/clusterStatusの値で確認できます。</p>
<p>ノードには「マスタ」と「フォロワ」という二つの役割があります。クラスタが開始する時には、クラスタを構成するノードのひとつが必ず「マスタ」になります。マスタはクラスタ全体の管理を行います。マスタ以外のノードはすべて「フォロワ」になります。フォロワは、マスタからの指示に基づいて同期などのクラスタ処理を行います。</p>
<table>
<thead>
<tr class="header">
<th>ノードの役割</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>MASTER</td>
<td>マスタ</td>
</tr>
<tr class="even">
<td>FOLLOWER</td>
<td>フォロワ</td>
</tr>
<tr class="odd">
<td>SUB_CLUSTER/SUB_MASTER</td>
<td>役割未定</td>
</tr>
</tbody>
</table></li>
</ul></li>
</ul>
<p><a id="status_of_cluster"></a></p>
<h3 data-number="4.1.2" id="クラスタのステータス" data-number="4.1.2"><span class="header-section-number">4.1.2</span> クラスタのステータス</h3>
<p>クラスタの稼働ステータスは各ノードの状態で決まり、そのステータスには稼働／中断／停止の3つの種類があります。</p>
<p>クラスタのサービスは、システムの初回構築時においては、ユーザが指定したクラスタ構成するノード数（構成ノード数）のノードがすべてクラスタに参加した時点で開始されます。</p>
<p>初回のクラスタ構築時、クラスタを構成するノードがすべてクラスタに組み入れられておらず、クラスタ構成待ちの状態が【INIT_WAIT】状態です。構成ノード数のノードがクラスタに参加完了した時点で状態は自動遷移し稼働状態となります。</p>
<p>稼働状態には【STABLE】と【UNSTABLE】の2つの状態があります。</p>
<ul>
<li>【STABLE】状態
<ul>
<li>構成ノード数で指定したノードの数でクラスタが構成されており、サービスが提供できている安定した状態。</li>
</ul></li>
<li>【UNSTABLE】状態
<ul>
<li>構成ノード数に満たない状態で、かつ、構成ノード数の過半数が稼働している状態</li>
<li>構成ノード数の過半数が稼働している限り、クラスタのサービスは継続します。</li>
</ul></li>
</ul>
<p>メンテナンスなどでノードをクラスタより切り離しても、構成ノード数の過半数が動作している限りクラスタは【UNSTABLE】状態で運用できます。</p>
<p>クラスタを構成するノードが、構成ノード数の半数以下となった場合、スプリットブレイン発生を防ぐためにクラスタは自動的にサービスを中断します。クラスタのステータスは【WAIT】状態となります。</p>
<ul>
<li><p>スプリットブレインとは、</p>
<p>複数のノードを相互接続して1台のサーバのように動作させる密結合クラスタシステムにおいて、ハードウェアやネットワークの障害によりシステムが分断されたことを契機に、同じ処理を行なう複数のクラスタシステムが同時にサービスを提供してしまう動作をいいます。この状態で運用を継続した場合、複数のクラスタでレプリカとして保有するデータをマスタデータとして動作してしまい、データの一貫性が取れない状態となってしまいます。</p></li>
</ul>
<p>【WAIT】状態からクラスタサービスを再開するには、エラーの回復したノードや新規のノードをノード追加操作でクラスタへ追加していきます。 再び構成ノード数のノードがクラスタに参加完了した時点で状態は【STABLE】状態となり、サービスが再開されます。</p>
<p>ノードの障害等でクラスタを構成するノード数が半数以下となり、クラスタのサービスが中断した場合でも、ノード追加操作でエラーの回復したノードや新規のノードをクラスタへ追加していき過半数のノードがクラスタに参加した時点で自動的にクラスタのサービスは再開されます。</p>
<figure>
<img src="img/arc_clusterStatus.png" alt="クラスタステータス" width="500"/>
<figcaption>クラスタステータス</figcaption>
</figure>

<p>STABLE状態はgs_statの示すjsonのパラメータである、/cluster/activeCountと/cluster/designatedCountの値が等しい状態です。</p>
<pre class="example"><code>$ gs_stat -u admin/admin
{
    &quot;checkpoint&quot;: {
        &quot;archiveLog&quot;: 0,
　　　　　：
　　　　　：
    },
    &quot;cluster&quot;: {
        &quot;activeCount&quot;:4,　　　　　　　　　　　 ★ クラスタ内で稼働中のノード
        &quot;clusterName&quot;: &quot;test-cluster&quot;,
        &quot;clusterStatus&quot;: &quot;MASTER&quot;,
        &quot;designatedCount&quot;: 4,                  ★ 構成ノード数
        &quot;loadBalancer&quot;: &quot;ACTIVE&quot;,
        &quot;master&quot;: {
            &quot;address&quot;: &quot;192.168.0.1&quot;,
            &quot;port&quot;: 10040
        },
        &quot;nodeList&quot;: [　　　　　　　　　　　　　★　クラスタを構成するマシンリスト
            {
                &quot;address&quot;: &quot;192.168.0.1&quot;,
                &quot;port&quot;: 10040
            },
            {
                &quot;address&quot;: &quot;192.168.0.2&quot;,
                &quot;port&quot;: 10040
            },
            {
                &quot;address&quot;: &quot;192.168.0.3&quot;,
                &quot;port&quot;: 10040
            },
            {
                &quot;address&quot;: &quot;192.168.0.4&quot;,
                &quot;port&quot;: 10040
            },

        ],
        ：
        ：
</code></pre>
<h3 data-number="4.1.3" id="パーティションのステータス" data-number="4.1.3"><span class="header-section-number">4.1.3</span> パーティションのステータス</h3>
<p>パーティションステータスは、クラスタ上のパーティション全体の状態を表します。クラスタステータスが稼働状態の時に、パーティションにアクセスできる状態か、パーティションに偏りが無いかなどを表すステータスです。</p>
<table>
<thead>
<tr class="header">
<th>パーティションステータス</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>NORMAL</td>
<td>すべてのパーティションがデータ配置目標と同一の正常な状態</td>
</tr>
<tr class="even">
<td>NOT_BALANCE</td>
<td>レプリカロスやオーナロスは発生していないが、パーティションの配置が偏っている状態</td>
</tr>
<tr class="odd">
<td>REPLICA_LOSS</td>
<td>レプリカのデータが欠損しているパーティションが存在する状態<br>（該当パーティションの可用性が落ちている・ノード離脱できない）</td>
</tr>
<tr class="even">
<td>OWNER_LOSS</td>
<td>オーナのデータが欠損しているパーティションが存在する状態<br>（該当パーティションのデータにはアクセスできない）</td>
</tr>
<tr class="odd">
<td>INITIAL</td>
<td>クラスタ構成に参加していない初期状態</td>
</tr>
</tbody>
</table>
<p>パーティションステータスは、マスタノードへのgs_statコマンドの実行で確認できます。（/cluster/partitionStatusの値）</p>
<pre class="example"><code>$ gs_stat -u admin/admin
{
　　：
　　：
&quot;cluster&quot;: {
    ：
    &quot;nodeStatus&quot;: &quot;ACTIVE&quot;,
    &quot;notificationMode&quot;: &quot;MULTICAST&quot;,
    &quot;partitionStatus&quot;: &quot;NORMAL&quot;,
    ：
</code></pre>
<p>[メモ]</p>
<ul>
<li>マスタノード以外の/cluster/partitionStatusの値は、正しくない場合があります。必ずマスタノードの値を確認してください。</li>
</ul>
<p><a id="cluster_configuration_methods"></a></p>
<h2 data-number="4.2" id="クラスタ構成方式" data-number="4.2"><span class="header-section-number">4.2</span> クラスタ構成方式</h2>
<p>クラスタは、ネットワーク上に存在するノード同士がお互いを認識することで構成されます。 ノードは、認識した他のノードのアドレスをリストとして持ちます。</p>
<p>GridDBは、アドレスリストを構成する方法が異なる3つのクラスタ構成方式を提供します。環境や利用ケースによってクラスタ構成方式を使い分けることができます。クラスタ構成方式によって、クライアントや運用ツールの接続方式も異なります。</p>
<p>クラスタ構成方式には、マルチキャスト方式と固定リスト方式とプロバイダ方式の3つがあります。推奨はマルチキャスト方式です。</p>
<p>固定リスト方式かプロバイダ方式を用いることで、マルチキャストが利用不可能な環境でのクラスタ構成、クライアント接続が可能になります。</p>
<ul>
<li>マルチキャスト方式
<ul>
<li>マルチキャストでノードのディスカバリを行い、アドレスリストを自動構成します。</li>
</ul></li>
<li>固定リスト方式
<ul>
<li>クラスタ定義ファイルに固定のアドレスリストを指定して起動することで、そのリストを利用します。</li>
</ul></li>
<li>プロバイダ方式
<ul>
<li>アドレスプロバイダが提供するアドレスリストを取得して利用します。</li>
<li>アドレスプロバイダはWebサービスとして構成するか、静的コンテンツとして構成することができます。</li>
</ul></li>
</ul>
<p>クラスタ構成方式の比較は以下のとおりです。</p>
<table>
<thead>
<tr class="header">
<th>項目</th>
<th>マルチキャスト方式(推奨)</th>
<th>固定リスト方式</th>
<th>プロバイダ方式</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>設定</td>
<td>・マルチキャストアドレス、ポート</td>
<td>・全ノードのIPアドレス:ポートのリスト</td>
<td>・プロバイダURL</td>
</tr>
<tr class="even">
<td>利用ケース</td>
<td>・マルチキャストが利用できる</td>
<td>・マルチキャストが利用できない<br>・正確にシステム規模の見積りが行える</td>
<td>・マルチキャストが利用できない<br>・システム規模が見積れない</td>
</tr>
<tr class="odd">
<td>クラスタ動作</td>
<td>・一定時間間隔でノードの自動ディスカバリを行う。</td>
<td>・全ノードに同一のアドレスリストを設定する<br>・ノード起動時に1度だけそのリストを読み込む</td>
<td>・アドレスプロバイダから一定時間間隔でアドレスリストを取得</td>
</tr>
<tr class="even">
<td>メリット</td>
<td>・ノード追加のためのクラスタ再起動不要</td>
<td>・リストの整合性チェックが行われるため、間違いが無い</td>
<td>・ノード追加のためのクラスタ再起動不要</td>
</tr>
<tr class="odd">
<td>デメリット</td>
<td>・クライアント接続にマルチキャストを要する</td>
<td>・ノード追加にクラスタ再起動が必要<br>・アプリ側の接続設定の更新も必要</td>
<td>・アドレスプロバイダの可用性確保が必要</td>
</tr>
</tbody>
</table>
<h3 data-number="4.2.1" id="クラスタ構成方式の設定" data-number="4.2.1"><span class="header-section-number">4.2.1</span> クラスタ構成方式の設定</h3>
<p>マルチキャスト方式が利用できない環境では、固定リスト方式またはプロバイダ方式でクラスタを構成します。 以下では、固定リスト方式とプロバイダ方式それぞれのネットワーク設定について説明します。</p>
<h4 data-number="4.2.1.1" id="固定リスト方式" data-number="4.2.1.1"><span class="header-section-number">4.2.1.1</span> 固定リスト方式</h4>
<p>固定のアドレスリストを与えてノードを起動することで、そのリストを利用してクラスタを構成します。</p>
<p>固定リスト方式でクラスタを構成する場合は、クラスタ定義ファイルのパラメータを設定します。</p>
<p><strong>クラスタ定義ファイル</strong></p>
<table>
<thead>
<tr class="header">
<th>パラメータ</th>
<th>データ型</th>
<th>意味</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>/cluster/notificationMember</td>
<td>string</td>
<td>クラスタ構成方式を固定リスト方式にする際に、アドレスリストを指定します。</td>
</tr>
</tbody>
</table>
<p>クラスタ定義ファイルの設定例は以下のとおりです。</p>
<pre class="example"><code>{
                             :
                             :
    &quot;cluster&quot;:{
        &quot;clusterName&quot;:&quot;yourClusterName&quot;,
        &quot;replicationNum&quot;:2,
        &quot;heartbeatInterval&quot;:&quot;5s&quot;,
        &quot;loadbalanceCheckInterval&quot;:&quot;180s&quot;,
        &quot;notificationMember&quot;: [
            {
                &quot;cluster&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10010},
                &quot;sync&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10020},
                &quot;system&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10040},
                &quot;transaction&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10001},
                &quot;sql&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:20001}
            },
            {
                &quot;cluster&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10010},
                &quot;sync&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10020},
                &quot;system&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10040},
                &quot;transaction&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10001},
                &quot;sql&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:20001}
            },
            {
                &quot;cluster&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10010},
                &quot;sync&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10020},
                &quot;system&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10040},
                &quot;transaction&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10001},
                &quot;sql&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:20001}
            }
        ]
    },
                             :
                             :
}
</code></pre>
<h4 data-number="4.2.1.2" id="プロバイダ方式" data-number="4.2.1.2"><span class="header-section-number">4.2.1.2</span> プロバイダ方式</h4>
<p>アドレスプロバイダが提供するアドレスリストを取得してクラスタ構成を行います。</p>
<p>プロバイダ方式でクラスタを構成する場合は、クラスタ定義ファイルのパラメータを設定します。</p>
<p><strong>クラスタ定義ファイル</strong></p>
<table>
<thead>
<tr class="header">
<th>パラメータ</th>
<th>データ型</th>
<th>意味</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>/cluster/notificationProvider/url</td>
<td>string</td>
<td>クラスタ構成方式をプロバイダ方式にする際に、アドレスプロバイダのURLを指定します。</td>
</tr>
<tr class="even">
<td>/cluster/notificationProvider/updateInterval</td>
<td>string</td>
<td>アドレスプロバイダからリストを取得する間隔を指定します。1s以上、2<sup>31</sup>s未満の値を指定します。</td>
</tr>
</tbody>
</table>
<p>クラスタ定義ファイルの設定例は以下のとおりです。</p>
<pre class="example"><code>{
                             :
                             :
    &quot;cluster&quot;:{
        &quot;clusterName&quot;:&quot;yourClusterName&quot;,
        &quot;replicationNum&quot;:2,
        &quot;heartbeatInterval&quot;:&quot;5s&quot;,
        &quot;loadbalanceCheckInterval&quot;:&quot;180s&quot;,
        &quot;notificationProvider&quot;:{
            &quot;url&quot;:&quot;http://example.com/notification/provider&quot;,
            &quot;updateInterval&quot;:&quot;30s&quot;
        }
    },
                             :
                             :
}
</code></pre>
<p>アドレスプロバイダはWebサービスとして構成するか、静的コンテンツとして構成することができます。 アドレスプロバイダは以下の仕様を満たす必要があります。</p>
<ul>
<li>GETメソッドに対応。</li>
<li>URLにアクセスすると、そのURLが書かれたクラスタ定義ファイルを持つクラスタのノードのアドレスリストをレスポンスとして返す。
<ul>
<li>レスポンスボディ：固定リスト方式において指定するノードリストの内容と同等のJSON</li>
<li>レスポンスヘッダ：Content-Type:application/jsonを含む</li>
</ul></li>
</ul>
<p>アドレスプロバイダからのレスポンスの例は以下のとおりです。</p>
<pre class="example"><code>$ curl http://example.com/notification/provider
[
    {
        &quot;cluster&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10010},
        &quot;sync&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10020},
        &quot;system&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10040},
        &quot;transaction&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:10001},
        &quot;sql&quot;: {&quot;address&quot;:&quot;172.17.0.44&quot;, &quot;port&quot;:20001}
    },
    {
        &quot;cluster&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10010},
        &quot;sync&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10020},
        &quot;system&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10040},
        &quot;transaction&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:10001},
        &quot;sql&quot;: {&quot;address&quot;:&quot;172.17.0.45&quot;, &quot;port&quot;:20001}
    },
    {
        &quot;cluster&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10010},
        &quot;sync&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10020},
        &quot;system&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10040},
        &quot;transaction&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:10001},
        &quot;sql&quot;: {&quot;address&quot;:&quot;172.17.0.46&quot;, &quot;port&quot;:20001}
    }
]
</code></pre>
<p>【メモ】</p>
<ul>
<li>各アドレスおよびポートはノード定義ファイルのserviceAddressおよびservicePortをモジュール(cluster,syncなど)ごとに指定します。</li>
<li>sqlの項目はGridDB Advanced Editionのみで必要となります。</li>
<li>クラスタ定義ファイルの/cluster/notificationAddress、/cluster/notificationMember、/cluster/notificationProviderは、使用するクラスタ構成方式に合わせていずれか1つを設定してください。</li>
</ul>
<p><a id="data_model"></a></p>
<h1 data-number="5" id="データモデル" data-number="5"><span class="header-section-number">5</span> データモデル</h1>
<p>GridDBは、Key-Valueに似た独自のKey-Container型データモデルです。以下の特徴があります。</p>
<ul>
<li>Key-Valueをグループ化するコンテナというRDBのテーブルに似た概念を導入</li>
<li>コンテナに対してデータ型を定義するスキーマ設定が可能。カラムにインデックスを設定可能。</li>
<li>コンテナ内のロウ単位でトランザクション操作が可能。また、コンテナ単位でACIDを保証します。</li>
</ul>
<figure>
<img src="img/arc_DataModel.png" alt="データモデル" width="650"/>
<figcaption>データモデル</figcaption>
</figure>

<p>GridDBのデータは、ブロック、コンテナ、テーブル、ロウ、パーティション、パーティショングループという単位でデータ管理されています。</p>
<ul>
<li><p>ブロック</p>
<p>ブロックとは、ディスクへのデータ永続化処理（以降、チェックポイントと呼びます）のデータ単位であり、GridDBの物理的なデータ管理の最小単位です。ブロックには複数のコンテナのデータが配置されます。ブロックサイズは、GridDBの初期起動前に定義ファイル（クラスタ定義ファイル）で設定します。</p>
<p>GridDBは、システムの初期起動とともにデータベースファイルが作成されるため、初期起動以降ブロックサイズの変更はできません。</p></li>
<li><p>コンテナ（テーブル）</p>
<p>利用者とのI/Fとなるデータ構造です。 複数のブロックで構成されます。 コンテナ（テーブル）には、コレクション（テーブル）と時系列コンテナ（時系列テーブル）の２種類のデータタイプが存在します。</p>
<p>アプリケーションでデータを登録する前には、必ずコンテナ（テーブル）を作成しておく必要があります。</p></li>
<li><p>ロウ</p>
<p>ロウは、コンテナやテーブルに登録される1行のデータを指します。コンテナやテーブルには複数のロウが登録されますが、データは同じブロックに配置されるわけではありません。登録・更新されるタイミングに応じて、パーティション内の適切なブロックに配置されます。</p>
<p>ロウは複数のデータ型のカラムから構成されます。</p></li>
<li><p>パーティション</p>
<p>パーティションは、1つ以上のコンテナやテーブルを含むデータ管理の単位です。</p>
<p>パーティションはクラスタ間でのデータ配置の単位であり、ノード間の負荷バランスを調整するためのデータ移動や、障害発生に備えたデータ多重化（レプリカ）管理のための単位です。データのレプリカはパーティション単位にクラスタを構成するノードに配置されます。</p>
<p>パーティション内のコンテナに対して更新操作ができるノードはオーナノードと呼ばれ、１つのパーティションに対して１つのノードが割り当てられます。オーナノード以外でレプリカを保持するノードは、バックアップノードとなります。パーティションには、レプリカの数の設定値に応じてマスタデータと複数のバックアップデータがあります。</p>
<p>コンテナとパーティションの関連は恒久的なもので、コンテナ作成時に、所属するパーティションが決定した後は変わりません。パーティションとノードの関連は一時的なもので、自律的データ配置によってパーティションが別のノード上に移動する場合があります。</p></li>
<li><p>パーティショングループ</p>
<p>複数のパーティションをグルーピングしてまとめた単位をパーティショングループと呼びます。</p>
<p>パーティショングループの保持するデータがOSのディスクに保存される物理的なデータベースファイルとなります。パーティショングループは、ノードで実行するデータベース処理スレッドの並列度に応じた数で作成されます。</p></li>
</ul>
<figure>
  <img src="img/arc_DataPieces.png" alt="データ管理の単位" width="900"/>
  <figcaption>データ管理の単位</figcaption>
</figure>

<p>　</p>
<p><a id="label_container"></a></p>
<h2 data-number="5.1" id="コンテナ" data-number="5.1"><span class="header-section-number">5.1</span> コンテナ</h2>
<p>GridDBにデータを登録し、検索するには、データを格納するコンテナ(テーブル)を作成する必要があります。</p>
<p>コンテナ(テーブル)もデータベースと同様の命名規則があります。</p>
<ul>
<li>指定可能な文字列は、英数字およびアンダースコア_、ハイフン-、ドット.、スラッシュ/、イコール=です。ただし、先頭文字に数字は指定できません。</li>
<li>命名時の大文字・小文字は保持されますが、大文字小文字を同一視した場合に同一名となるコンテナ(テーブル)は作成できません。</li>
</ul>
<h3 data-number="5.1.1" id="種別" data-number="5.1.1"><span class="header-section-number">5.1.1</span> 種別</h3>
<p>コンテナ(テーブル)には、2つのデータタイプがあります。時々刻々発生するデータを発生した時刻とともに管理するのに適したデータタイプである <strong>時系列コンテナ(時系列テーブル)</strong> とさまざまなデータを管理する <strong>コレクション(テーブル)</strong> です。</p>
<h3 data-number="5.1.2" id="データ型" data-number="5.1.2"><span class="header-section-number">5.1.2</span> データ型</h3>
<p>コンテナ(テーブル)にはスキーマを設定できます。登録できるデータ型には、基本的なデータ型である <strong>基本型</strong> と <strong>配列型</strong> があります。</p>
<h4 data-number="5.1.2.1" id="基本型" data-number="5.1.2.1"><span class="header-section-number">5.1.2.1</span> 基本型</h4>
<p>登録できる基本型のデータを説明します。基本型とは、他の型の組み合わせで表現できない、基本的な型です。</p>
<table>
<thead>
<tr class="header">
<th>データ型</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>BOOL型</td>
<td>真または偽のいずれかの値</td>
</tr>
<tr class="even">
<td>STRING型</td>
<td>Unicodeコードポイントを文字とする、任意個数の文字の列より構成</td>
</tr>
<tr class="odd">
<td>BYTE型</td>
<td>-2<sup>7</sup>から2<sup>7</sup>-1 (8ビット)の整数値</td>
</tr>
<tr class="even">
<td>SHORT型</td>
<td>-2<sup>15</sup>から2<sup>15</sup>-1 (16ビット)の整数値</td>
</tr>
<tr class="odd">
<td>INTEGER型</td>
<td>-2<sup>31</sup>から2<sup>31</sup>-1 (32ビット)の整数値</td>
</tr>
<tr class="even">
<td>LONG型</td>
<td>-2<sup>63</sup>から2<sup>63</sup>-1 (64ビット) の整数値</td>
</tr>
<tr class="odd">
<td>FLOAT型</td>
<td>IEEE754で定められた単精度型(32ビット)浮動小数点数</td>
</tr>
<tr class="even">
<td>DOUBLE型</td>
<td>IEEE754で定められた倍精度型(64ビット)浮動小数点数</td>
</tr>
<tr class="odd">
<td>TIMESTAMP型</td>
<td>年月日ならびに時分秒からなる時刻を表す型。データベースに保持されるデータ形式はUTCで、精度はミリ秒</td>
</tr>
<tr class="even">
<td>GEOMETRY型</td>
<td>空間構造を表すためのデータ型</td>
</tr>
<tr class="odd">
<td>BLOB型</td>
<td>画像や音声などのバイナリデータのためのデータ型</td>
</tr>
</tbody>
</table>
<p>STRING型､GEOMETRY型、BLOB型は管理できるデータのサイズに以下の制限があります。制限値は、GridDBの定義ファイル（gs_node.json）のデータベースの入出力単位であるブロックサイズに応じて値が異なります。</p>
<table>
<thead>
<tr class="header">
<th>型</th>
<th>ブロックサイズ(64KB)</th>
<th>ブロックサイズ (1MB～32MB)</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>STRING型</td>
<td>最大31KB (UTF-8エンコード相当)</td>
<td>最大128KB (UTF-8エンコード相当)</td>
</tr>
<tr class="even">
<td>GEOMETRY型</td>
<td>最大31KB (内部格納形式相当)</td>
<td>最大128KB (内部格納形式相当)</td>
</tr>
<tr class="odd">
<td>BLOB型</td>
<td>最大1GB - 1Byte</td>
<td>最大1GB - 1Byte</td>
</tr>
</tbody>
</table>
<p><strong>GEOMETRY型(空間型)</strong></p>
<p>GEOMETRY型（空間型）のデータは地図情報システムなどでよく利用されています。空間型のデータは、NoSQLインターフェースでのみ使用できます。NewSQLインターフェースでは未サポートです。</p>
<p>GEOMETRY型のデータは、WKT（Well-known text）を用いて記述します。WKTは、地理空間に関する情報の標準化などを推進している非営利団体OGC(Open Geospatial Consortium)にて策定されています。GridDBでは、コンテナのカラムをGEOMETRY型に設定することで、WKTで記述された空間情報をカラムに格納できます。</p>
<p>GEOMETRY型では以下のWKT形式をサポートします。</p>
<ul>
<li>POINT
<ul>
<li>2次元または3次元の座標により生成される点。</li>
<li>記述例： POINT(0 10 10)</li>
</ul></li>
<li>LINESTRING
<ul>
<li>2つ以上の点により表現される、2次元または3次元空間上の直線の集合。</li>
<li>記述例： LINESTRING(0 10 10, 10 10 10, 10 10 0)</li>
</ul></li>
<li>POLYGON
<ul>
<li>直線の集合により表現される、2次元または3次元空間上の閉じた領域。POLYGONの頂点は反時計回りに指定します。POLYGON内に島をつくる場合、内部の点は時計回りで指定します。</li>
<li>記述例： POLYGON((0 0,10 0,10 10,0 10,0 0))、POLYGON ((35 10, 45 45, 15 40, 10 20, 35 10),(20 30, 35 35, 30 20, 20 30))</li>
</ul></li>
<li>POLYHEDRALSURFACE
<ul>
<li>2次元または3次元の座標により生成される点</li>
<li>記述例： POLYHEDRALSURFACE (((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 0 1 0, 0 1 1, 0 0 1, 0 0 0)),((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 1, 1 0 1, 0 0 1, 0 1 1, 1 1 1)),((1 1 1, 1 0 1, 1 0 0, 1 1 0, 1 1 1)),((1 1 1, 1 1 0, 0 1 0, 0 1 1, 1 1 1)) )</li>
</ul></li>
<li>QUADRATICSURFACE
<ul>
<li>定義式f(X) = &lt;AX, X&gt; + BX + cにより表現される、3次元空間上の2次曲面。</li>
</ul></li>
</ul>
<p>ただし、空間構造QUADRATICSURFACEはコンテナに登録することはできず、検索条件としてのみ使用できます。</p>
<p>GEOMETRY型を利用した演算は、APIやTQLで実行できます。</p>
<p>TQLでは2次元、3次元の空間を定義する空間生成関数と空間型データ間での演算の関数を提供します。TQLではコンテナ内のGEOMETRY型のカラムと指定した空間データで演算を行いその結果を以下のようにして得ることができます。</p>
<pre class="example"><code> SELECT * WHERE ST_MBRIntersects(geom, ST_GeomFromText(&#39;POLYGON((0 0,10 0,10 10,0 10,0 0))&#39;))
</code></pre>
<h4 data-number="5.1.2.2" id="複合型" data-number="5.1.2.2"><span class="header-section-number">5.1.2.2</span> 複合型</h4>
<p>コンテナに登録できる、基本型の組み合わせで構成される型を定義します。 現バージョンでは配列型のみです。</p>
<ul>
<li><p>配列型</p>
<p>値の列を表します。基本型のデータの内、GEOMETRY型とBLOB型を除く基本型を配列型として、データを保持することができます。配列で保持できるデータ量の制限は、データベースのブロックサイズに応じて値が異なります。</p>
<table>
<thead>
<tr class="header">
<th>型</th>
<th>ブロックサイズ(64KB)</th>
<th>ブロックサイズ (1MB～32MB)</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>配列数</td>
<td>4000</td>
<td>65000</td>
</tr>
</tbody>
</table></li>
</ul>
<p>【メモ】</p>
<p>配列型カラムでは、TQLでの操作に以下の制約があります。</p>
<ul>
<li><p>配列型カラムのi番目の値の比較はできますが、全要素に関する演算（集計演算）はできません。</p></li>
<li><p>（例）columnAが配列型で定義されたとした場合</p>
<ul>
<li><p>select * where ELEMENT(0, columnA) &gt; 0 のような配列内の要素を指定した比較はできます。ただし、ELEMENTの"0"の部分に変数は指定できません。</p></li>
<li><p>select SUM(columnA) のような集計計算はできません。</p></li>
</ul></li>
</ul>
<p><a id="primary_key"></a></p>
<h3 data-number="5.1.3" id="主キー" data-number="5.1.3"><span class="header-section-number">5.1.3</span> 主キー</h3>
<p>コンテナ(テーブル)には、主キーを設定できます。主キーによって、コンテナ(テーブル)のロウの一意性を保障します。また主キーを設定したカラムには、NULL値を許容しません。</p>
<p>主キーは、コンテナではROWKEY(ロウキー)、テーブルではPRIMARY KEY(プライマリキー)と呼びます。</p>
<ul>
<li>時系列コンテナ（時系列テーブル）の場合
<ul>
<li>ROWKEY(PRIMARY KEY)は先頭カラムに設定できます。（GridDBではカラムを0番から数えるため、カラム番号0に設定します。）</li>
<li>ROWKEY(PRIMARY KEY)は、TIMESTAMP型です。</li>
<li>指定は必須です。</li>
</ul></li>
<li>コレクション(テーブル)の場合
<ul>
<li>ROWKEY(PRIMARY KEY)は先頭カラムより連続した複数のカラムに設定できます。ロウキーを複数のカラムに設定した場合は、複合ロウキーと呼びます。設定できるカラム数の上限は16個です。</li>
<li>ROWKEY(PRIMARY KEY)は、STRING、INTEGER、LONG、TIMESTAMPのいずれかの型のカラムです。</li>
<li>指定は必須ではありません。</li>
</ul></li>
</ul>
<p>ROWKEY(PRIMARY KEY)に設定したカラムには、カラムの型に応じてあらかじめ既定された、デフォルトの索引が設定されます。</p>
<p>GridDBの現バージョンでは、ROWKEY(PRIMARY KEY)に指定できるSTRING、INTEGER、LONG、TIMESTAMPのすべての型のデフォルトの索引はTREE索引です。</p>
<p>　　　</p>
<h1 data-number="6" id="データベース機能" data-number="6"><span class="header-section-number">6</span> データベース機能</h1>
<h2 data-number="6.1" id="リソースの管理" data-number="6.1"><span class="header-section-number">6.1</span> リソースの管理</h2>
<p>GridDBのクラスタを構成するリソースには、メモリ上のデータベースのほかにディスク上に永続化されるリソースがあります。 永続化リソースには、以下のものがあります。</p>
<ul>
<li><p>データベースファイル</p>
<p>クラスタを構成するノードの保有するデータをディスクやSSDに書き込み、永続化したファイル群です。データベースファイルは、定期的にメモリ上のデータベースが書き込まれるチェックポイントファイルと、データ更新の都度保存されるトランザクションログファイルを総称します。</p></li>
<li><p>チェックポイントファイル</p>
<p>パーティショングループがディスクに永続化されたファイルです。ノード定義ファイルのサイクル（/checkpoint/checkpointInterval）でメモリ上の更新情報が反映されます。 ファイルのサイズはデータ容量に応じて拡張されます。一度拡張されたデータファイルのサイズは、コンテナやロウなどのデータを削除しても減少しません。なお、データ削除後の空き領域は再利用されます。チェックポイントファイルは複数に分割して配置することも可能です。</p></li>
<li><p>トランザクションログファイル</p>
<p>トランザクションの更新情報がログとしてシーケンシャルに保存されるファイルです。</p></li>
<li><p>定義ファイル</p>
<p>クラスタを構成する際のパラメータファイル（gs_cluster.json：以降、クラスタ定義ファイルと呼ぶ）と、クラスタ内でのノードの動作やリソースを設定するパラメータファイル（gs_node.json：以降、ノード定義ファイルと呼ぶ）の２つがあります。また、ユーザ定義ファイルもあります。</p></li>
<li><p>イベントログファイル</p>
<p>GridDBサーバのイベントログが保存されます。イベントログにはエラーや警告などのメッセージが含まれます。</p></li>
</ul>
<figure>
<img src="img/arc_DatabaseFile.png" alt="データベースファイル" width="800"/>
<figcaption>データベースファイル</figcaption>
</figure>

<h2 data-number="6.2" id="データアクセス機能" data-number="6.2"><span class="header-section-number">6.2</span> データアクセス機能</h2>
<p>GridDBのデータにアクセスするには、NoSQLインターフェースもしくはNewSQLインターフェース(GridDB AEのみ)を用いてアプリケーションを開発する必要があります。データアクセスでは、コンテナやテーブルがクラスタデータベースのどこに配置されているかの位置情報を意識する必要はなく、GridDBのクラスタデータベースに接続するだけでアクセスができます。コンテナがクラスタを構成するどのノードに配置されているのかをアプリケーションシステムが意識する必要はありません。</p>
<p>GridDBのAPIでは、クラスタデータベースへの初期接続時に、ノード情報（パーティション）とともにコンテナの配置ヒント情報をクライアント側に保持（キャッシュ）します。</p>
<p>アプリケーションが利用するコンテナが切り替わる度に、配置されているノードを探す処理のためクラスタにアクセスする必要はなく、コンテナを保持するノードに直に接続して処理をするため、通信のオーバヘッドを最小限としています。</p>
<p>GridDBではリバランス処理により、コンテナ配置は動的に変わりますが、クライアントキャッシュは定期的に更新されるため、コンテナの位置は透過です。タイミングによってクライアントからのアクセスでノードがミスヒットした時でも、自動的に再配置情報を取得して処理を継続します。</p>
<p><a id="tql"></a></p>
<h3 data-number="6.2.1" id="tql" data-number="6.2.1"><span class="header-section-number">6.2.1</span> TQL</h3>
<p>データベースのアクセス言語として、TQLをサポートしています。</p>
<ul>
<li><p>TQLとは</p>
<p>簡易版SQLとして、コンテナを単位とした検索、集計演算などの機能をサポートします。TQLはNoSQLインターフェースから利用します。</p>
<p>TQLは、小規模なコンテナに対して少量ヒットするような検索に適しています。データ量・ヒット件数が少ない場合には、SQLより低いレイテンシで検索できることが特徴です。ヒット件数を少量にする手段の一つとして、TQL構文のLIMIT節の指定があります。</p></li>
</ul>
<p><a id="batch_functions"></a></p>
<h3 data-number="6.2.2" id="複数コンテナへの一括処理機能" data-number="6.2.2"><span class="header-section-number">6.2.2</span> 複数コンテナへの一括処理機能</h3>
<p>GridDBが提供するNoSQL I/Fでは、時々刻々発生するイベント情報を高速に処理するためのインターフェースを用意しています。</p>
<p>大量に発生するイベントを発生の都度データベースサーバに送信していると、ネットワークへの負荷が高くなりシステムのスループットがあがりません。通信回線帯域が狭い場合特に顕著な影響がでます。NoSQL I/Fでは複数のコンテナに対する複数のロウの登録や、複数のコンテナへの複数の問い合わせ(TQL)を1リクエストで処理するためのマルチ処理が用意されています。頻繁にデータベースサーバにアクセスしないため、システム全体のスループットがあがります。</p>
<p>以下に例を挙げます。</p>
<ul>
<li><p>マルチプット(multiput)</p>
<ul>
<li><p>複数のセンサのイベント情報をデータベースに登録する処理として、センサ名毎にコンテナを用意します。センサ名とセンサの時系列イベントのロウ配列を作り、複数のセンサ分まとめたリスト(Map)を作成します。このリストデータを1回のAPI呼び出しでGridDBのデータベースに登録します。</p></li>
<li><p>マルチプットのAPIでは、複数クラスタからなるGridDBのノードに対して、１個以上のコンテナへの登録要求をまとめて行うことで通信処理を効率化します。また、マルチ登録処理では、トランザクション実行時のMVCCは行わず、高速に処理します。</p></li>
<li><p>マルチプットでは、トランザクションのコミットは、autocommitとなります。1件単位にデータが確定されます。</p></li>
</ul></li>
</ul>
<figure>
<img src="img/func_multiput.png" alt="multiput処理" width="500"/>
<figcaption>multiput処理</figcaption>
</figure>

<ul>
<li><p>マルチクエリ(fetchAll)</p>
<ul>
<li>センサのイベント情報を集計する処理などで、コンテナへのクエリ問い合わせを複数実行するのではなく、１つの問い合わせで実行することができます。たとえば、センサから取得したデータの一日の最大値、最小値、平均値などの集計結果の取得や、最大値や最小値をもつロウ集合や特定の条件に合致するロウ集合といったロウ集合のデータ取得を最適化します。</li>
</ul></li>
</ul>
<figure>
<img src="img/func_multiquery.png" alt="fetchAll処理" width="500"/>
<figcaption>fetchAll処理</figcaption>
</figure>

<ul>
<li><p>マルチゲット(multiget)</p>
<ul>
<li><p>センサのイベント情報を取得する処理などで複数機器のRowkeyを指定した一括データ取得ができます。 RowKeyPredicateオブジェクトにデータ取得の条件を設定し、複数の機器のデータを一括で取得します。</p></li>
<li><p>RowKeyPredicateオブジェクトでは以下の2形式のいずれかで取得条件を設定します。</p>
<ul>
<li>取得範囲の指定</li>
<li>指定した個別の値</li>
</ul></li>
</ul></li>
</ul>
<figure>
<img src="img/func_multiget.png" alt="multiget処理" width="500"/>
<figcaption>multiget処理</figcaption>
</figure>

<p><a id="index_function"></a></p>
<h2 data-number="6.3" id="索引機能" data-number="6.3"><span class="header-section-number">6.3</span> 索引機能</h2>
<p>コンテナ(テーブル)のカラムに対し索引を作成することで、条件付き検索が高速に処理できます。</p>
<p>索引タイプにはハッシュ索引(HASH)、ツリー索引(TREE)、空間索引(SPATIAL)の3種類があります。 ハッシュ索引は、コンテナ内のクエリでの検索時の等価検索で利用します。ツリー索引は、等価検索のほかに、範囲（より大きい/等しい、より小さい/等しいなど）を含む参照に利用します。</p>
<p>設定できる索引はコンテナ(テーブル)のタイプやカラムのデータ型に応じて異なります。</p>
<ul>
<li>ハッシュ索引（HASH）
<ul>
<li>等価検索を高速に行えますが、ロウをシーケンシャル（逐次的）に読み込んでいくような検索には向いていません。</li>
<li>コレクションにおける次に示す型のカラムに対して設定できます。時系列コンテナ、テーブル、時系列テーブルには設定できません。
<ul>
<li>STRING</li>
<li>BOOL</li>
<li>BYTE</li>
<li>SHORT</li>
<li>INTEGER</li>
<li>LONG</li>
<li>FLOAT</li>
<li>DOUBLE</li>
<li>TIMESTAMP</li>
</ul></li>
</ul></li>
<li>ツリー索引（TREE）
<ul>
<li>等価検索のほかに、範囲（より大きい/等しい、より小さい/等しいなど）を含む参照に利用します。</li>
<li>時系列コンテナ(時系列コレクション)のROWKEY(PRIMARY KEY)に対応するカラムを除く、任意種別のコンテナ（テーブル）における次に示す型のカラムに対して設定できます。
<ul>
<li>STRING</li>
<li>BOOL</li>
<li>BYTE</li>
<li>SHORT</li>
<li>INTEGER</li>
<li>LONG</li>
<li>FLOAT</li>
<li>DOUBLE</li>
<li>TIMESTAMP</li>
</ul></li>
<li>ツリー索引のみ、複数のカラムを指定した索引を作成できます。これを複合索引と呼びます。1つの複合索引に指定できるカラム数の上限は16個で、同じカラムを複数回指定することはできません。</li>
</ul></li>
<li>空間索引（SPATIAL）
<ul>
<li>コレクションにおけるGEOMETRY型カラムに対してのみ設定できます。空間検索を高速に行う場合に指定します。</li>
</ul></li>
</ul>
<p>コンテナに作成できる索引の数に制限はありませんが、索引の作成は慎重に設計する必要があります。索引は、設定されたコンテナのロウに対して挿入、更新、または削除の各操作が実行されると更新されます。したがって、頻繁に更新されるロウのカラムに多数の索引を作成すると、挿入、更新、または削除の各操作でパフォーマンスに影響ができます。</p>
<p>索引は以下のようなカラムに作成します。</p>
<ul>
<li>頻繁に検索されたり、ソートされたりするカラム</li>
<li>TQLのWHERE節の条件で頻繁に使用されるカラム</li>
<li>カーディナリティの高い（重複した値があまり含まれない）カラム</li>
</ul>
<p>【メモ】</p>
<ul>
<li>テーブル（時系列テーブル）のカラムには、ツリー索引のみ設定できます。</li>
</ul>
<p><a id="ts_data_functions"></a></p>
<h2 data-number="6.4" id="時系列データ特有の機能" data-number="6.4"><span class="header-section-number">6.4</span> 時系列データ特有の機能</h2>
<p>GridDBでは、高頻度で発生するセンサなどのデータ管理のために、メモリを最大限有効利用するデータ配置アルゴリズム(TDPA：Time Series Data Placement Algorithm)に従いデータ配置処理します。時系列コンテナ(時系列テーブル)では、内部データを周期性で分類しながらメモリ配置します。アフィニティ機能でヒント情報を与えるとさらに配置効率が上がります。また、データは必要に応じてディスクに追い出しながら、ほぼゼロコストで有効期限切れのデータを解放しています。</p>
<p>時系列コンテナ(時系列テーブル)は、TIMESTAMP型のROWKEY(PRIMARY KEY)を持ちます。</p>
<h3 data-number="6.4.1" id="圧縮機能" data-number="6.4.1"><span class="header-section-number">6.4.1</span> 圧縮機能</h3>
<p>時系列コンテナ（時系列テーブル）は、データを圧縮して保持することができます。 圧縮オプションの指定は時系列コンテナ（時系列テーブル）作成時に指定します。データを圧縮することでメモリ使用効率を上げることができます。</p>
<p>ただし、圧縮オプションが設定されている時系列コンテナ(時系列テーブル)に対しては、以下に示すロウ操作を行えませんので注意してください。</p>
<ul>
<li>指定ロウの更新</li>
<li>指定ロウの削除</li>
<li>指定時刻より新しい時刻のロウが存在する場合の、ロウの新規作成</li>
</ul>
<p>圧縮オプションには次の指定ができます。</p>
<ul>
<li>HI ：誤差あり間引き圧縮方式であることを示します。</li>
<li>NO ：無圧縮であることを示します。</li>
<li>SS ：誤差なし間引き圧縮方式であることを示します。</li>
</ul>
<p>それぞれのオプションの内容は以下のとおりです。</p>
<h4 data-number="6.4.1.1" id="誤差あり間引き圧縮hi" data-number="6.4.1.1"><span class="header-section-number">6.4.1.1</span> 誤差あり間引き圧縮(HI)</h4>
<p>誤差あり間引き圧縮(HI)では、前回までおよび直後に登録したデータと同じ傾斜を表すロウは省かれます。同じ傾斜かを判定する条件はユーザが指定できます。</p>
<p>指定されたカラムが条件を満たし、それ以外のカラムの値が前回のデータと同じ場合のみロウデータは省かれます。条件は、誤差の幅(Width)で指定します。</p>
<figure>
  <img src="img/func_TimeseriseCompression.png" alt="時系列コンテナ(時系列テーブル)の圧縮" width="700"/>
  <figcaption>時系列コンテナ(時系列テーブル)の圧縮</figcaption>
</figure>

<p>圧縮の指定を設定できるデータタイプは以下です。</p>
<ul>
<li>LONG</li>
<li>INTEGER</li>
<li>SHORT</li>
<li>BYTE</li>
<li>FLOAT</li>
<li>DOUBLE</li>
</ul>
<p>圧縮は不可逆圧縮のため、間引き圧縮で間引かれたデータをデータ登録時のままの値で復元することはできません。</p>
<p>省かれたデータはinterpolate(補完)やsample(サンプリング)処理の際に、指定された誤差の範囲内で復元できます。</p>
<h4 data-number="6.4.1.2" id="誤差なし間引き圧縮ss" data-number="6.4.1.2"><span class="header-section-number">6.4.1.2</span> 誤差なし間引き圧縮(SS)</h4>
<p>誤差なし間引き圧縮(SS)では、直前および直後に登録したロウと同じデータを持つロウは省かれます。省かれたデータはinterpolateやsample処理の際に、誤差を発生することなく復元できます。</p>
<h3 data-number="6.4.2" id="tqlの演算機能" data-number="6.4.2"><span class="header-section-number">6.4.2</span> TQLの演算機能</h3>
<h4 data-number="6.4.2.1" id="集計演算" data-number="6.4.2.1"><span class="header-section-number">6.4.2.1</span> 集計演算</h4>
<p>採取したデータの時間間隔でデータに重みをつけて計算します。つまり、時間間隔が長い場合、長時間その値が続いたことを想定した計算となります。</p>
<p>集計演算には以下の関数があります。</p>
<ul>
<li><p>TIME_AVG</p>
<ul>
<li>重み付きで平均を求める演算です。</li>
<li>検索の条件に合致した各ロウについて、前後それぞれの時刻のロウとの中間時刻間の期間を特定の単位で換算したものを、重み付け値として使用します。条件で指定した時刻のロウのみが存在しない場合は、存在しないロウの代わりに条件に指定した時刻の直前、直後のロウを用いて重みづけ計算をします。</li>
<li>計算の詳細イメージを図示します。</li>
</ul></li>
</ul>
<figure>
  <img src="img/func_TIME_AVG.png" alt="重みづけの集計演算（TIME_AVG)" width="500"/>
  <figcaption>重みづけの集計演算（TIME_AVG)</figcaption>
</figure>

<h4 data-number="6.4.2.2" id="選択補間演算" data-number="6.4.2.2"><span class="header-section-number">6.4.2.2</span> 選択・補間演算</h4>
<p>時刻データは、収集されるデータの内容や収集タイミングにより想定した時刻より多少の時間のずれが発生することがあります。したがって時刻データをキーにして検索する際にも、指定した時刻周辺のデータが取得できる機能が必要です。</p>
<p>時系列コンテナ(時系列テーブル)を検索し、指定したロウを取得するための以下のような関数があります。</p>
<ul>
<li><p>TIME_NEXT(*, timestamp)</p>
<p>指定の時刻と同一またはその直後の時刻を持つ1つのロウを選択します。</p></li>
<li><p>TIME_NEXT_ONLY(*, timestamp)</p>
<p>指定の時刻の直後の時刻を持つ1つのロウを選択します。</p></li>
<li><p>TIME_PREV(*, timestamp)</p>
<p>指定の時刻と同一またはその直前の時刻を持つ1つのロウを選択します。</p></li>
<li><p>TIME_PREV_ONLY(*, timestamp)</p>
<p>指定の時刻の直前の時刻を持つ1つのロウを選択します。</p></li>
</ul>
<p>また、実体のロウのカラムの値を補間演算で計算するための以下のような関数があります。</p>
<ul>
<li><p>TIME_INTERPOLATED(column, timestamp)</p>
<p>指定の時刻に関して、一致するロウの指定のカラムの値、または、隣接する前後のロウの指定カラムの値を線形補間して得られた値を求めます。</p></li>
<li><p>TIME_SAMPLING(*|column, timestamp_start, timestamp_end, interval, DAY|HOUR|MINUTE|SECOND|MILLISECOND)</p>
<p>開始・終了時刻を指定して、特定範囲のロウ集合をサンプリングします。</p>
<p>サンプリング位置の時刻は、開始時刻に対し非負整数倍のサンプリング間隔を加えた時刻のうち、終了時刻と同じかそれ以前のもののみです。</p>
<p>各サンプリング位置の時刻と一致するロウが存在する場合は該当ロウの値を使用します。存在しない場合は補間された値を使用します。</p></li>
</ul>
<h3 data-number="6.4.3" id="期限解放機能" data-number="6.4.3"><span class="header-section-number">6.4.3</span> 期限解放機能</h3>
<p>期限解放とは、設定した保持期間を超えたロウデータを、検索や削除などの操作対象から外して参照不可とした後、DBから物理的に削除する機能です。 利用されなくなった古いデータを操作の対象から外して削除することで、DBサイズを一定に保ち、データベースサイズ肥大化によるパフォーマンス低下を防ぐことができます。</p>
<figure>
<img src="img/func_expiration.png" alt="期限解放" width="700"/>
<figcaption>期限解放</figcaption>
</figure>

<p>保持期間はコンテナ単位に設定します。保持期間を越えたロウを「期限切れデータ」と呼びます。期限切れデータは参照不可となってAPIから操作できなくなるので、アプリケーションからはそのロウは存在しない状態になります。期限切れデータは、一定期間が経過すると、DBから物理的に削除する対象のデータになります。この削除対象となった期限切れデータを「コールドデータ」と呼びます。コールドデータは、そのまま自動的にDBから削除することも可能ですし、データを残しておく必要がある場合は外部ファイルに保存してから自動削除することもできます。</p>
<h4 data-number="6.4.3.1" id="期限解放の種類" data-number="6.4.3.1"><span class="header-section-number">6.4.3.1</span> 期限解放の種類</h4>
<ul>
<li><p>ロウ期限解放</p>
<ul>
<li>時系列コンテナに対して設定できます。</li>
<li>設定項目は、保持期間、保持期間の単位、分割数です。</li>
<li>保持期間の単位として設定できるのは、日/時/分/秒/ミリ秒の単位です。年単位、月単位の指定はできません。</li>
<li>ロウの保持期限は、ロウキーに格納された日時(保持期間開始日)に保持期間を足した日時です。保持期限はロウごとに計算します。</li>
<li>コールドデータになる単位は、「保持期間÷分割数」の期間のロウです。たとえば、期間が720日で分割数指定が36の場合、720日÷36=20日間のロウ単位でコールドデータになり、物理的データ削除は20日分まとめて行なわれます。</li>
</ul></li>
</ul>
<figure>
<img src="img/func_expiration_row.png" alt="ロウ期限解放" width="700"/>
<figcaption>ロウ期限解放</figcaption>
</figure>

<p>【メモ】</p>
<ul>
<li><p>期限解放の設定は、コンテナ作成時に行います。作成後に設定を変更することはできません。</p></li>
<li><p>保持期限超過の判定に使用される現在時刻は、GridDBの各ノードの実行環境に依存します。したがって、ネットワークの遅延や実行環境の時刻設定のずれなどにより、クライアントの時刻よりGridDBのノードの時刻が進んでいる場合、期限切れ前のロウにアクセスできなくなる場合があります。逆にクライアントの時刻のみ進んでいる場合は、期限切れロウにアクセスできる場合があります。意図しないロウの喪失を避けるために、最低限必要な期間よりも大きな値を設定することを推奨します。</p></li>
<li><p>期限切れのロウは、検索や更新といったロウ操作の対象から外れ、存在しないものとみなされます。期限切れのロウに対して行われた操作はエラーにはなりません。</p>
<ul>
<li>例) 保持期限が30日の設定の場合、現在から31日前の日時のロウを登録しても登録処理はエラーにはならず、かつ、コンテナにはそのロウは保存されません。</li>
</ul></li>
<li><p>期限解放を設定する場合は、必ずクラスタの全ノードの時刻を同期してください。時刻がずれていると、ノード間で期限解放されるタイミングが異なるなどの問題が生じる場合があります。</p></li>
<li><p>期限切れデータからコールドデータになるまでの期間は、期限解放の保持期間の設定によって異なります。</p>
<table>
<thead>
<tr class="header">
<th>保持期間</th>
<th>期限切れからコールドデータになるまでの最大期間</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>～3日</td>
<td>約1.2時間</td>
</tr>
<tr class="even">
<td>3日～12日</td>
<td>約5時間</td>
</tr>
<tr class="odd">
<td>12日～48日</td>
<td>約19時間</td>
</tr>
<tr class="even">
<td>48日～192日</td>
<td>約3日</td>
</tr>
<tr class="odd">
<td>192日～768日</td>
<td>約13日</td>
</tr>
<tr class="even">
<td>768日～</td>
<td>約38日</td>
</tr>
</tbody>
</table></li>
</ul>
<h2 data-number="6.5" id="トランザクション機能" data-number="6.5"><span class="header-section-number">6.5</span> トランザクション機能</h2>
<p>GridDBではコンテナ単位のトランザクション処理をサポートし、トランザクションの特性として一般的に言われるACID特性をサポートしています。以下にトランザクション処理でサポートしている機能の詳細を説明していきます。</p>
<h3 data-number="6.5.1" id="トランザクションの開始と終了" data-number="6.5.1"><span class="header-section-number">6.5.1</span> トランザクションの開始と終了</h3>
<p>コンテナに対して、ロウの検索・更新などの操作を行なったときに新たなトランザクションが開始され、データの更新結果を確定(コミット)または破棄(アボート)した時にトランザクションが終了します。</p>
<p>【メモ】</p>
<ul>
<li>コミットとは、処理中のトランザクションの情報を確定し、データを永続化させる処理です。
<ul>
<li>GridDBではコミット処理でトランザクションの更新したデータがトランザクションログとして保管され、保持していたロックが解放されます。</li>
</ul></li>
<li>アボートとは、トランザクションの処理途中のデータをすべてロールバックする（処理を取り消す）処理です。
<ul>
<li>GridDBでは処理途中のデータはすべて破棄され、保持していたロックも解放されます。</li>
</ul></li>
</ul>
<p>トランザクションの初期の動作はautocommit（自動コミット）に設定されています。</p>
<p>autocommitでは、アプリケーションからのコンテナに対する更新（データの追加、削除、変更）操作開始毎に新たなトランザクションが開始され、操作終了とともに自動的にコミットされます。 autocommitをオフにすることで、アプリケーションからの要求に応じたタイミングでトランザクションのコミット、アボートを指示できます。</p>
<p>トランザクションのライフサイクルは、トランザクションのコミットやアボートによる完了とともにタイムアウトによるエラー終了があります。トランザクションがタイムアウトによりエラー終了した場合、そのトランザクションはアボートされます。トランザクションのタイムアウトは、トランザクションが開始してからの経過時間です。 トランザクションのタイムアウト時間は、アプリケーション単位にGridDBに接続する際のパラメータとして指定することができます。また、タイムアウト時間の上限値はノード定義ファイル（gs_node.json）に設定できます。</p>
<h3 data-number="6.5.2" id="トランザクションの一貫性レベル" data-number="6.5.2"><span class="header-section-number">6.5.2</span> トランザクションの一貫性レベル</h3>
<p>トランザクションの一貫性レベルにはimmediate consistencyとeventual consistencyの2種類があります。この指定はアプリケーションごとにGridDBに接続する際のパラメータとして指定することもできます。 デフォルトはimmediate consistencyです。</p>
<ul>
<li><p>immediate consistency</p>
<ul>
<li>コンテナに対する他のクライアントからの更新結果は、該当トランザクションの完了後即座に反映されます。そのため、常に最新の内容を参照します。</li>
</ul></li>
<li><p>eventual consistency</p>
<ul>
<li>コンテナに対する他のクライアントからの更新結果は、該当トランザクションが完了した後でも反映されていない場合があります。 そのため、古い内容を参照する能性があります。</li>
</ul></li>
</ul>
<p>immediate consistencyは更新操作、読み取り操作で有効です。 eventual consistencyは読み取り操作でのみ有効です。 常に最新の結果を読み取る必要のないアプリケーションではeventual consistencyを指定すると読み取り性能が向上します。</p>
<h3 data-number="6.5.3" id="トランザクションの隔離レベル" data-number="6.5.3"><span class="header-section-number">6.5.3</span> トランザクションの隔離レベル</h3>
<p>データベースの内容は常に整合性が保たれている必要があります。 複数のトランザクションを同時実行させたとき、一般に以下の現象が課題として挙がります。</p>
<ul>
<li><p>ダーティリード</p>
<p>トランザクションが書き込んだコミットされていないデータを、別のトランザクションで読み込んでしまう現象です。</p></li>
<li><p>反復不能読み取り</p>
<p>トランザクション内で以前読み込んだデータを再読み込みできなくなる現象です。トランザクション内で以前読み込んだデータを再度読み込もうとしても、別のトランザクションがそのデータを更新、コミットしたために、以前のデータが読み込めなくなります(更新後の新しいデータを読み込むことになります)</p></li>
<li><p>ファントムリード</p>
<p>トランザクション内で以前得られた問い合わせの結果が得られなくなる現象です。トランザクション内で以前実行した問い合わせを再実行しても、別のトランザクションがその問い合わせ条件を満たすデータを変更、追加し、コミットしたために、同じ条件で問い合わせを実行しても、以前の結果が得られなくなります(更新後のデータを得ることになります)。</p></li>
</ul>
<p>GridDBでは、トランザクションの隔離レベルとして「READ_COMMITTED」をサポートしています。 READ_COMMITTEDでは、確定した最新データを常に読み取ります。</p>
<p>トランザクションを実行する場合、他のトランザクションからの影響を受けないように配慮する必要があります。隔離レベルは、実行トランザクションを他のトランザクションからどの程度隔離するか(どの程度整合性を保てるか)を示す指標であり、4つのレベルがあります。</p>
<p>4つの隔離レベルおよび、それに対して同時実行時の課題であげた現象が起こる可能性は以下のとおりです。</p>
<table>
<thead>
<tr class="header">
<th>隔離レベル</th>
<th>ダーティリード</th>
<th>反復不能読み取り</th>
<th>ファントムリード</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>READ_UNCOMMITTED</td>
<td>発生の可能性あり</td>
<td>発生の可能性あり</td>
<td>発生の可能性あり</td>
</tr>
<tr class="even">
<td>READ_COMMITTED</td>
<td>安全</td>
<td>発生の可能性あり</td>
<td>発生の可能性あり</td>
</tr>
<tr class="odd">
<td>REPEATABLE_READ</td>
<td>安全</td>
<td>安全</td>
<td>発生の可能性あり</td>
</tr>
<tr class="even">
<td>SERIALIZABLE</td>
<td>安全</td>
<td>安全</td>
<td>安全</td>
</tr>
</tbody>
</table>
<p>READ_COMMITEDでは、以前読み込んだデータを再度読み込んだ場合に、以前のデータとは異なるデータを得たり、問い合わせを再実行した場合に、同じ検索条件で問い合わせを実行しても異なる結果を得てしまうことがあります。これは前回の読み込み後に、別のトランザクションによって更新、コミットが行われ、データが更新されたためです。</p>
<p>GridDBでは、MVCCによって、更新中のデータを隔離しています。</p>
<h3 data-number="6.5.4" id="mvcc" data-number="6.5.4"><span class="header-section-number">6.5.4</span> MVCC</h3>
<p>GridDBでは、READ_COMMITTEDを実現するために「MVCC(Multi-Version Concurrency Control：多版型同時実行制御方式)」を採用しています。</p>
<p>MVCCとは、各トランザクションがデータベースに対して問い合わせるときに、別のトランザクションが更新中の最新のデータでなく、更新前のデータを参照して処理を行う方式です。更新前のデータを参照してトランザクションを並行実行できるため、システムのスルー プットが向上します。</p>
<p>実行中のトランザクションの処理がコミットすると、他のトランザクションも最新のデータを参照できます。</p>
<figure>
<img src="img/func_MVCC.png" alt="MVCC" width="700"/>
<figcaption>MVCC</figcaption>
</figure>

<h3 data-number="6.5.5" id="ロック" data-number="6.5.5"><span class="header-section-number">6.5.5</span> ロック</h3>
<p>コンテナに対する複数トランザクションからの更新処理要求競合時の一貫性を保つため、データのロック機構があります。</p>
<p>ロックの粒度は、コンテナの種別に応じて異なります。またロックの範囲は、データベースへの操作の種別に応じて異なります。</p>
<h4 data-number="6.5.5.1" id="ロックの粒度" data-number="6.5.5.1"><span class="header-section-number">6.5.5.1</span> ロックの粒度</h4>
<p>コンテナの種別ごとのロックの粒度は次のとおりです。</p>
<ul>
<li>コレクション・・・ロウ単位でロックします。</li>
<li>時系列コンテナ・・・ロウ集合でロックされます。
<ul>
<li>時系列コンテナは、ブロックをいくつかに分割したデータ処理の単位に複数のロウを配置します。 このデータ処理の単位をロウ集合とよびます。コレクションでのロックの粒度よりもデータ粒度が荒いですが、大量に発生する時系列コンテナを高速に処理するためのデータの管理の単位です。</li>
</ul></li>
</ul>
<p>これらは、コンテナの種別ごとのユースケースの分析に基づいています。</p>
<ul>
<li>コレクションデータはRDBのテーブルと同様にデータを管理するため、既存のロウデータが更新されるケースがある</li>
<li>時系列コンテナは時々刻々発生するデータを保持するデータ構造であり、特定の時刻のデータが更新されるケースは少ない</li>
</ul>
<h4 data-number="6.5.5.2" id="データベース操作によるロック範囲" data-number="6.5.5.2"><span class="header-section-number">6.5.5.2</span> データベース操作によるロック範囲</h4>
<p>コンテナへの操作にはデータの登録、削除のみならず、データ構造の変更に伴うスキーマ変更や、アクセス高速化のための索引作成などの操作があります。ロック範囲は、コンテナ全体への操作、またはコンテナのロウ単位の操作のいずれかによって異なります。</p>
<ul>
<li><p>コンテナ単位のロック</p>
<ul>
<li>索引操作(createIndex/dropIndex)</li>
<li>コンテナ削除</li>
<li>スキーマ変更</li>
</ul></li>
<li><p>ロックの粒度に従ったロック</p>
<ul>
<li>put/update/remove</li>
<li>get(forUpdate)</li>
</ul>
<p>ロウへのデータ操作ではロックの粒度に沿ったロックを確保します。</p></li>
</ul>
<p>ロック確保で競合した場合、先行したトランザクションがコミットもしくはロールバック処理で実行が完了しロックを解放するまで、後続のトランザクションはロック確保待ちとなります。</p>
<p>ロック確保待ちは、トランザクションの実行完了以外では、タイムアウトでも解消されます。</p>
<h3 data-number="6.5.6" id="データ永続化" data-number="6.5.6"><span class="header-section-number">6.5.6</span> データ永続化</h3>
<p>コンテナやテーブルに登録・更新されたデータは、ディスクやSSDに永続化され、ノード障害発生時のデータ消失から保護されます。メモリ上の更新データをブロック単位にデータベースファイルに定期的に保存するチェックポイント処理と、データ更新に同期して更新データをシーケンシャルにトランザクションログファイルに書き込むトランザクションログ処理の２つの処理があります。</p>
<p>トランザクションログの書き込みには、以下のいずれかをノード定義ファイルに設定できます。</p>
<ul>
<li>0: SYNC</li>
<li>1以上の整数値: DELAYED_SYNC</li>
</ul>
<p>"SYNC"では、更新トランザクションのコミット・アボートごとに、ログ書き込みを同期的に行います。"DELAYED_SYNC"では、更新時のログ書き込みを、更新タイミングとは関係なく、指定秒数毎に遅延して行います。デフォルト値は"1(DELAYED_SYNC 1秒)"です。</p>
<p>"SYNC"を指定するとノード障害発生時に最新の更新内容を消失する可能性が低くなりますが更新が多いシステムでは性能に影響します。</p>
<p>一方、"DELAYED_SYNC"を指定すると、更新性能は向上しますが、ノード障害発生時ディスクに書き込まれていない更新内容があるとそれらが失われます。</p>
<p>クラスタ構成でレプリカ数が2以上の場合は、他のノードにレプリカを持つため、"DELAYED_SYNC"設定でも1ノード障害時に最新の更新内容を失う可能性は低くなります。 更新頻度が高く、性能が要求される場合には、"DELAYED_SYNC"を設定することも考慮してください。</p>
<p>チェックポイントでは、更新ブロックをデータベースファイルに更新します。 チェックポイント処理は、ノード単位に設定したサイクルで動作します。チェックポイントのサイクルはノード定義ファイルのパラメータで設定します。初期値は、60秒です。</p>
<p>チェックポイントの実行サイクルの数値を上げることで、ディスクへの永続化を夜間に実施するなど比較的時間に余裕がある時間帯に設定することができます。一方サイクルを長くした場合に、システム処理外でノードを再起動した際にロールフォワードすべきトランザクションログファイルが増え、リカバリ時間が増えるという欠点もあります。</p>
<p>チェックポイント実行時に更新のあったデータは、チェックポイントの書き込みブロックとは別のメモリにプールし、保持します。 チェックポイントを高速に行うにはチェックポイントの並列実行を設定します。並列実行を設定した場合、トランザクションの同時実行数と同じ数まで並列で処理されます。</p>
<figure>
<img src="img/func_checkpnt.png" alt="チェックポイント" width="500"/>
<figcaption>チェックポイント</figcaption>
</figure>

<h3 data-number="6.5.7" id="タイムアウト処理" data-number="6.5.7"><span class="header-section-number">6.5.7</span> タイムアウト処理</h3>
<h4 data-number="6.5.7.1" id="nosql-ifのタイムアウト処理" data-number="6.5.7.1"><span class="header-section-number">6.5.7.1</span> NoSQL I/Fのタイムアウト処理</h4>
<p>NoSQL I/Fでは、アプリケーション開発者に通知されるタイムアウトには2種類のタイムアウトがあります。アプリケーションの処理時間の制限に関するトランザクションタイムアウトと、障害発生時の回復処理のリトライ時間に関するフェイルオーバータイムアウトの２つです。</p>
<ul>
<li><p>トランザクションタイムアウト（transactionTimeout）</p>
<p>処理対象のコンテナにアクセスを開始してからタイマが開始され、指定した時間を超えるとタイムアウトが発生します。</p>
<p>長時間更新ロックを保有するトランザクション（更新モードで検索し、ロックを保持したまま解放しないアプリケーション）や長時間大量の結果セットを保持するトランザクション（長時間、クラスタシステムのメモリを解放しないアプリケーション）などからロックやメモリを解放するために用意されたタイムアウト時間です。トランザクションタイムアウトに達したらアプリケーションはアボートされます。</p>
<p>トランザクションタイムアウトは、クラスタ接続時のパラメータとしてアプリケーションで指定できます。タイムアウト時間の上限値はノード定義ファイルで指定します。 タイムアウト時間の上限値の初期値は300秒です。処理に長時間かかるトランザクションの発生を監視をするためには、システムの要件に合わせてタイムアウト時間とその上限値を設定してください。</p></li>
<li><p>フェイルオーバータイムアウト（failoverTimeout）</p>
<p>クラスタを構成するノードに障害が発生したとき、ノードに接続しているクライアントが代替えノードに接続する際のエラーリトライ時のタイムアウト時間です。リトライ処理で新たな接続先が見つかった場合、クライアントアプリケーションにはエラーは通知されません。フェイルオーバータイムアウトは、初期接続時のタイムアウトにも利用されます。</p>
<p>フェイルオーバータイムアウトは、クラスタ接続時のパラメータとしてアプリケーションで指定できます。システムの要件に合わせてタイムアウト時間を設定してください。</p></li>
</ul>
<p>トランザクションタイムアウト、フェイルオーバータイムアウトともに、Java APIやC APIでGridStoreオブジェクトを用いてクラスタに接続する際に設定できます。　</p>
<h2 data-number="6.6" id="レプリケーション機能" data-number="6.6"><span class="header-section-number">6.6</span> レプリケーション機能</h2>
<p>クラスタを構成する複数のノード間では、ユーザが設定したレプリケーション数に従って、パーティション単位にデータのレプリカが作成されます。</p>
<p>データのレプリカを分散ノード間で保持することで、ノード障害が発生しても、ノンストップで処理を継続できます。クライアントAPIでは、ノードの障害を検出すると、自動的にレプリカを保持する別ノードにアクセスを切り替えます。</p>
<p>レプリケーション数のデフォルト値は2で、複数ノードのクラスタ構成で動作した場合、データが2重化されます。</p>
<p>コンテナに更新があると、多重化されたパーティションのうちオーナノード（レプリカのマスタを持つノード）が更新されます。</p>
<p>その後オーナノードから更新内容がバックアップノードに反映されますが、その方法は2つあります。</p>
<ul>
<li><p>非同期レプリケーション</p>
<p>更新処理のタイミングと同期せずにレプリケーションを行います。準同期レプリケーションに対して更新性能に優れますが、可用性では劣ります。</p></li>
<li><p>準同期レプリケーション</p>
<p>更新処理のタイミングで同期的にレプリケーションを行いますが、レプリケーション完了の待ち合わせは行いません。可用性の面では優れますが、性能面では劣ります。</p></li>
</ul>
<p>可用性よりも性能を重視する場合は非同期レプリケーションに、可用性を重視する場合は準同期レプリケーションに設定してください。</p>
<p>【メモ】</p>
<ul>
<li>レプリケーション数の設定は、クラスタ定義ファイル（gs_cluster.json)の/cluster/replicationNumで設定します。 レプリケーションの同期設定は、クラスタ定義ファイル（gs_cluster.json)の/transaction/replicationModeで設定します。</li>
</ul>
<h2 data-number="6.7" id="アフィニティ機能" data-number="6.7"><span class="header-section-number">6.7</span> アフィニティ機能</h2>
<p>アフィニティとは、関連のあるデータを結びつける機能です。GridDBには、アフィニティ機能としてデータアフィニティとノードアフィニティの２つの機能があります。</p>
<h3 data-number="6.7.1" id="データアフィニティ機能" data-number="6.7.1"><span class="header-section-number">6.7.1</span> データアフィニティ機能</h3>
<p>データアフィニティとは、関連の強いデータを同じブロックに配置し、データアクセスの局所化を図ることでメモリヒット率を高めるための機能です。メモリヒット率を高めることで、データアクセス時のメモリミスヒットを減らし、スループットを高めることができます。データアフィニティを利用することで小メモリマシンでもメモリを有効活用して動作させることができます。</p>
<p>データアフィニティの設定はコンテナ(テーブル)作成時にプロパティとしてヒント情報を与えます。ヒント情報は、コンテナ(テーブル)名の命名規則と同様に指定できる文字に制限があります。同じヒント情報があるデータをできるだけ同じブロックに配置します。</p>
<p>データアフィニティのヒント情報は、データの更新頻度や参照頻度に応じて設定します。 たとえば、分単位、日単位、月単位、年単位にデータをサンプリングや参照する監視システムに対して、以下のような利用方法でシステムのデータが登録・参照・更新される場合のデータ構造を考えます。</p>
<ol>
<li>監視機器から分単位のデータが送信され、監視機器単位に作成したコンテナにデータを保存</li>
<li>日単位のデータレポート作成のため、一日分のデータの集計を分単位データから行い、日単位コンテナ(テーブル)に保存</li>
<li>月単位のデータレポート作成のため、日単位コンテナ(テーブル)のデータの集計を行い、月単位コンテナ(テーブル)に保存</li>
<li>年単位のデータレポート作成のため、月単位コンテナ(テーブル)のデータの集計を行い、年単位コンテナ(テーブル)に保存</li>
<li>カレントの使用量（分単位、日単位）は常に表示パネルに更新表示</li>
</ol>
<p>GridDBでは、コンテナ単位にブロックを占有するのではなく、ブロックには時刻の近いデータが配置されます。したがって、2.の日単位コンテナ(テーブル)を参照し、月単位の集計を行い集計時間をROWKEY(PRIMARY KEY)とする3.のデータと、分単位の1.のデータが同一ブロックに保存される可能性があります。</p>
<p>メモリが小さく監視データがすべてメモリに収まらない大容量データで4.の年単位の集計処理を行なう場合、ブロックが分断して配置された3.のデータをメモリに配置するために、常時必要な1．のデータがメモリから追い出されるなど、直近でないデータの読み込みにより監視したいデータがスワップアウトされる状況が発生します。</p>
<p>この場合データアフィニティで、分単位、日単位、月単位などコンテナ(テーブル)のアクセス頻度に沿ったヒントを与えることで、アクセス頻度の低いデータと高いデータをデータ配置時に別ブロックに分離します。</p>
<p>このように、データアフィニティ機能によってアプリケーションの利用シーンに合わせたデータ配置ができます。</p>
<figure>
<img src="img/feature_data_afinity.png" alt="データアフィニティ" width="500"/>
<figcaption>データアフィニティ</figcaption>
</figure>

<h3 data-number="6.7.2" id="ノードアフィニティ機能" data-number="6.7.2"><span class="header-section-number">6.7.2</span> ノードアフィニティ機能</h3>
<p>ノードアフィニティとは、関連の強いコンテナやテーブルを同じノードに配置し、データアクセス時のネットワーク負荷を減少させるための機能です。</p>
<figure>
<img src="img/func_Node_Affinity.png" alt="ノードアフィニティによるコンテナ/テーブルの配置" width="500"/>
<figcaption>ノードアフィニティによるコンテナ/テーブルの配置</figcaption>
</figure>

<p>ノードアフィニティ機能を利用するには、コンテナ(テーブル)作成時にコンテナ(テーブル)名にヒント情報を与えます。ヒント情報が同一のコンテナ(テーブル)は同一のパーティションに配置されます。 以下のように指定します。</p>
<ul>
<li>コンテナ(テーブル)名@ノードアフィニティヒント情報</li>
</ul>
<p>ノードアフィニティのヒント情報の命名もコンテナ(テーブル)名の命名規則と同様です。</p>
<h2 data-number="6.8" id="トリガ機能" data-number="6.8"><span class="header-section-number">6.8</span> トリガ機能</h2>
<p>トリガ機能とは、コンテナのロウデータへの操作（登録／更新もしくは削除）が行われた際に、Java Messaging Service(JMS)またはRESTを用いて自動的に通知する機能です。 アプリケーションシステムでデータベースの更新をポーリングして監視する必要はなく、事象の通知をうけることができます。</p>
<figure>
<img src="img/func_trigger.png" alt="トリガ機能の動作" width="500"/>
<figcaption>トリガ機能の動作</figcaption>
</figure>

<ul>
<li><p>通知方法</p>
<ul>
<li>アプリケーションシステムへの通知方法は、以下の2種類です。
<ul>
<li>Java Messaging Service(JMS)</li>
<li>REST</li>
</ul></li>
</ul></li>
<li><p>操作</p>
<ul>
<li>操作できる機能は、トリガ設定、トリガ解除、トリガ情報取得の3つです。</li>
</ul></li>
<li><p>通知タイミング</p>
<ul>
<li>ロウの新規作成または更新、削除が行われたタイミングで通知を行ないます。</li>
<li>レプリケーション完了までは待ちません。また、自動コミットモードでない場合は、未コミットの状態で通知を行ないます。</li>
</ul></li>
<li><p>通知内容</p>
<ul>
<li>コンテナ名、操作の種類(ロウの新規作成または更新、削除)を通知します。</li>
<li>通知対象カラムの指定がある場合、操作が行われたロウの指定されたカラムの値も併せて通知します。</li>
</ul></li>
<li><p>エラー発生時の処理</p>
<ul>
<li>通知時にエラーが発生した場合はイベントログにエラー情報を記録します。再送は行いません。</li>
</ul></li>
<li><p>その他</p>
<ul>
<li>複数のロウを一括して新規作成・更新する操作を行った場合、個別のロウ単位で通知を行ないます。この操作は、Java APIの場合Container#put(java.util.Collection)もしくはGridStore#multiPut(Map)の呼び出しに相当します。</li>
<li>トリガが設定されたコンテナのスキーマを変更した場合、トリガは変更後のコンテナに引き継がれますが、変更後のスキーマに含まれないカラムは通知対象カラム名集合から自動的に削除されます。</li>
<li>同一のコンテナに対しJMS通知とREST通知の両方を設定することは可能ですが、トリガ名は別にする必要があります。</li>
</ul></li>
</ul>
<p>【注意】</p>
<ul>
<li>トリガと更新性能に関する注意
<ul>
<li>トリガが発火するコンテナ数、および発火するトリガ数に応じて更新性能が低下します。トリガが必要なコンテナだけに最小限のトリガ付与を行うようにしてください。</li>
</ul></li>
<li>トリガ通知先サーバの処理性能に関する注意
<ul>
<li>GridDBの更新処理のスループットに比べて通知先サーバのスループットが極端に低い場合、トリガ処理に失敗し、イベントログにエラーメッセージが記録されることがあります。トリガ設定されているコンテナを高頻度で更新する場合、通知先サーバの性能も確認して調整してください。</li>
</ul></li>
</ul>
<h2 data-number="6.9" id="コンテナテーブルの定義変更" data-number="6.9"><span class="header-section-number">6.9</span> コンテナ(テーブル)の定義変更</h2>
<p>コンテナ作成後に、カラム追加などのコンテナ定義の変更を行うことができます。</p>
<h3 data-number="6.9.1" id="カラム追加" data-number="6.9.1"><span class="header-section-number">6.9.1</span> カラム追加</h3>
<p>コンテナに新しいカラムを追加します。</p>
<ul>
<li>NoSQL APIの場合
<ul>
<li>GridStore#putContainerを用いてカラム追加します。</li>
<li>既存コンテナからコンテナ情報情報ContainerInfoを取得し、コンテナ情報に新しいカラムをセットしてからputContainerを実行します。</li>
<li>【プログラム例】
<div class="sourceCode" id="cb7"><pre class="sourceCode java"><code class="sourceCode java"><span id="cb7-1"><a href="#cb7-1"></a><span class="co">// コンテナ情報を取得</span></span>
<span id="cb7-2"><a href="#cb7-2"></a>ContainerInfo conInfo = store.<span class="fu">getContainerInfo</span>(<span class="st">&quot;table1&quot;</span>);</span>
<span id="cb7-3"><a href="#cb7-3"></a><span class="bu">List</span>&lt;ColumnInfo&gt; newColumnList = <span class="kw">new</span> <span class="bu">ArrayList</span>&lt;ColumnInfo&gt;();</span>
<span id="cb7-4"><a href="#cb7-4"></a><span class="kw">for</span> ( <span class="dt">int</span> i = <span class="dv">0</span>; i &lt; conInfo.<span class="fu">getColumnCount</span>(); i++ ){</span>
<span id="cb7-5"><a href="#cb7-5"></a>    newColumnList.<span class="fu">add</span>(conInfo.<span class="fu">getColumnInfo</span>(i));</span>
<span id="cb7-6"><a href="#cb7-6"></a>}</span>
<span id="cb7-7"><a href="#cb7-7"></a><span class="co">// 新しいカラムを末尾にセット</span></span>
<span id="cb7-8"><a href="#cb7-8"></a>newColumnList.<span class="fu">add</span>(<span class="kw">new</span> <span class="fu">ColumnInfo</span>(<span class="st">&quot;NewColumn&quot;</span>, GSType.<span class="fu">INTEGER</span>));</span>
<span id="cb7-9"><a href="#cb7-9"></a>conInfo.<span class="fu">setColumnInfoList</span>(newColumnList);</span>
<span id="cb7-10"><a href="#cb7-10"></a></span>
<span id="cb7-11"><a href="#cb7-11"></a><span class="co">// カラム追加</span></span>
<span id="cb7-12"><a href="#cb7-12"></a>store.<span class="fu">putCollection</span>(<span class="st">&quot;table1&quot;</span>, conInfo, <span class="kw">true</span>);</span></code></pre></div></li>
</ul></li>
</ul>
<p>カラムを追加した後に既存ロウを取得した場合、追加カラムの値はカラムのデータ型ごとに定義されている「空の値」が返ります。</p>
<figure>
<img src="img/add_column.png" alt="カラム追加の例" width="800"/>
<figcaption>カラム追加の例</figcaption>
</figure>

<h3 data-number="6.9.2" id="カラム削除" data-number="6.9.2"><span class="header-section-number">6.9.2</span> カラム削除</h3>
<p>コンテナのカラムを削除します。NoSQL APIのみで操作できます。</p>
<ul>
<li>NoSQL API
<ul>
<li>GridStore#putContainerを用いてカラム削除します。既存コンテナからコンテナ情報ContainerInfoを取得し、削除対象のカラム情報を除いてからputContainerを実行します。</li>
</ul></li>
</ul>
<h2 data-number="6.10" id="データベース圧縮解放機能" data-number="6.10"><span class="header-section-number">6.10</span> データベース圧縮/解放機能</h2>
<p><a id="block_data_compression"></a></p>
<h3 data-number="6.10.1" id="データブロック圧縮" data-number="6.10.1"><span class="header-section-number">6.10.1</span> データブロック圧縮</h3>
<p>GridDBは、メモリ上のデータをデータベースファイルに書き込むことで、メモリサイズに依存しない大容量化を実現できますが、ストレージのコストは増加します。データブロック圧縮機能は、データベースファイル（チェックポイントファイル）を圧縮することで、データ量に伴って増加するストレージコストの削減を支援する機能です。 特に、HDDと比べ容量単価が高いフラッシュメモリをより効率的に活用できます。</p>
<p><strong>圧縮方法</strong></p>
<p>メモリ上のデータをデータベースファイル（チェックポイントファイル）に書き出す際に、GridDBの書き出し単位であるブロック毎に圧縮操作を行います。圧縮により空いた領域は、Linuxのファイルブロック割り当て解除処理を行うため、ディスク使用量を削減できます。</p>
<p><strong>サポート環境</strong></p>
<p>データブロック圧縮はLinuxの機能を利用しているため、Linuxカーネルバージョンとファイルシステムに依存します。データブロック圧縮のサポート環境は以下です。</p>
<ul>
<li>OS: RHEL / CentOS 7.2以上</li>
<li>ファイルシステム：XFS</li>
<li>ファイルシステムのブロックサイズ：4KB</li>
</ul>
<p>　※上記以外の環境でデータブロック圧縮を有効にした場合、GridDBノードの起動に失敗します。</p>
<p><strong>設定方法</strong></p>
<p>GridDBノードごとに圧縮機能を設定します。</p>
<ul>
<li>ノード定義ファイル(gs_node.json)の/datastore/storeCompressionModeに以下の文字列を設定します。
<ul>
<li>圧縮機能を無効にする場合：NO_COMPRESSION（既定値）</li>
<li>圧縮機能を有効にする場合：COMPRESSION</li>
</ul></li>
<li>GridDBノード起動時（再起動時）に設定を適用します。</li>
<li>GridDBノードを再起動することで、圧縮機能の動作を有効/無効に変更することができます。</li>
</ul>
<p>【注意】</p>
<ul>
<li>データブロック圧縮の対象は、チェックポイントファイルのみです。トランザクションログファイル、バックアップファイル、およびGridDBのメモリ上のデータは圧縮しません。</li>
<li>データブロック圧縮により、チェックポイントファイルはスパースファイルになります。</li>
<li>圧縮機能を有効に変更しても、すでにチェックポイントファイルに書き込み済みのデータは圧縮できません。</li>
</ul>
<h3 data-number="6.10.2" id="データブロック未使用領域解放" data-number="6.10.2"><span class="header-section-number">6.10.2</span> データブロック未使用領域解放</h3>
<p>データブロック未使用領域解放機能は、データベースファイル（チェックポイントファイル）の使用されていないブロック領域に対して、Linuxのファイルブロック割り当て解除処理を行い、データベースファイルのサイズ(実ディスク割当量)を縮小することができる機能です。</p>
<p>以下のようなケースにおいて、ディスク使用量を削減したい場合にご利用ください。</p>
<ul>
<li>データを大量に削除した場合</li>
<li>今後データ更新の予定が無く、DBを長期保存するような場合</li>
<li>データ更新時にディスクフルになり、回避する暫定手段としてDBサイズ縮小が必要な場合</li>
</ul>
<p>未使用領域を解放する処理や、本機能のサポート環境、実行方法について説明します。</p>
<p><strong>解放処理</strong></p>
<p>GridDBノード起動時に、データベースファイル（チェックポイントファイル）の未使用領域を解放します。 解放された領域は、新たなデータ更新が発生しない限りディスク領域は割り当てられません。</p>
<p><strong>サポート環境</strong></p>
<p>サポート環境は、<a href="#block_data_compression">データブロック圧縮</a>機能と同じです。</p>
<p><strong>実行方法</strong></p>
<p>GridDBノード起動時に、gs_startnodeコマンドでデータブロック未使用領域解放オプション(--releaseUnusedFileBlocks)を指定します。</p>
<p>データベースファイル（チェックポイントファイル）の未使用領域サイズとディスク割当サイズは、下記の方法で確認してください。</p>
<ul>
<li>gs_statコマンドで表示される項目
<ul>
<li><p>storeTotalUse</p>
<p>ノードがチェックポイントファイルで保有する全データ容量(バイト)</p></li>
<li><p>checkpointFileAllocateSize</p>
<p>チェックポイントファイルに割り当てられたブロックの総サイズ(バイト)</p></li>
</ul></li>
</ul>
<p>データブロック未使用領域解放機能の実施目安としては、データブロック未使用領域が多い(上記の値の比較で、storeTotalUse ≪ checkpointFileAllocateSize) 場合です。</p>
<p>【注意】</p>
<ul>
<li>本機能の対象は、チェックポイントファイルのみです。トランザクションログファイル、バックアップファイルの未使用領域は解放しません。</li>
<li>本機能を実施すると、チェックポイントファイルはスパースファイルになります。</li>
<li>チェックポイントファイルのディスク使用量は削減できますが、スパースファイルになることでフラグメントが発生しやすくなり、性能面ではデメリットになる可能性があります。</li>
<li>起動時に領域解放処理が行われるため、通常の起動処理より時間がかかる場合があります。</li>
</ul>
<p><a id="label_parameters"></a></p>
<h1 data-number="7" id="パラメータ" data-number="7"><span class="header-section-number">7</span> パラメータ</h1>
<p>GridDBの動作を制御するパラメータについて説明します。GridDBのパラメータにはノードの設定情報や利用できるリソースなどの設定を行うノード定義ファイルと、クラスタの動作設定を行うクラスタ定義ファイルがあります。 定義ファイルの項目名と初期状態での設定値とパラメータの意味を説明します。</p>
<p>設定値の単位は以下のように指定します。</p>
<ul>
<li><p>バイトサイズ: TB、GB、MB、KB、B、T、G、M、K、またはこれらの小文字表記で指定可能。特に記載のない限り、単位の省略はできません。</p></li>
<li><p>時間: h、min、s、msで指定可能。特に記載のない限り、単位の省略はできません。</p></li>
</ul>
<p>　</p>
<h2 data-number="7.1" id="クラスタ定義ファイルgs_clusterjson" data-number="7.1"><span class="header-section-number">7.1</span> クラスタ定義ファイル（gs_cluster.json)</h2>
<p>クラスタ定義ファイルは、クラスタを構成する全ノードで同一の設定にしておく必要があります。partitionNum,storeBlockSizeパラメータはデータベースの構造を決める重要なパラメータのため、GridDBの初期起動後は値の変更ができません。</p>
<p>クラスタ定義ファイルの各設定項目の意味を以下に説明します。</p>
<p>初期状態で含まれていない項目も項目名を追加することでシステムに認識させることができます。 変更の欄ではパラメータの変更可否と変更タイミングを示します</p>
<ul>
<li>変更不可　：ノードを一度起動したのちは変更はできません。変更したい場合データベースを初期化する必要があります。</li>
<li>起動　　　：クラスタを構成する全ノードを再起動することで、変更できます。</li>
<li>オンライン：オンライン稼働中にパラメータを変更できます。ただし、変更内容は永続化されないため、定義ファイルの内容を手動で変更する必要があります。</li>
</ul>
<p>　</p>
<table>
<thead>
<tr class="header">
<th>GridDBの構成</th>
<th>初期値</th>
<th>パラメータの意味と制限値</th>
<th>変更</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>/notificationAddress</td>
<td>239.0.0.1</td>
<td>マルチキャストアドレスの標準設定です。cluster,transactionの同じ名前のパラメータが省略された場合、本設定が有効になります。異なる値が設定されている場合、個別設定のアドレスが有効です。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/dataStore/partitionNum</td>
<td>128</td>
<td>パーティション数を構成するクラスタ台数で分割配置できる公倍数で指定します。 整数: 1以上、10000以下で指定します。</td>
<td>変更不可</td>
</tr>
<tr class="odd">
<td>/dataStore/storeBlockSize</td>
<td>64KB</td>
<td>ディスクI/Oのサイズ(64KB,1MB,4MB,8MB,16MB,32MB)を指定します。ブロックサイズを大きくすると１ブロックに格納できるレコードが増えるため、大規模テーブルのフルスキャンに向きますが、競合が発生する可能性が高くなります。システムにあったサイズを十分に検討して設定してください。サーバ起動後は変更できません。</td>
<td>変更不可</td>
</tr>
<tr class="even">
<td>/cluster/clusterName</td>
<td>なし</td>
<td>クラスタを識別するための名称を指定します。必須入力のパラメータです。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/cluster/replicationNum</td>
<td>2</td>
<td>レプリカ数を指定します。レプリカ数が2の場合、パーティションが2重化されます。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/cluster/notificationAddress</td>
<td>239.0.0.1</td>
<td>クラスタ構成用マルチキャストアドレスを指定します。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/cluster/notificationPort</td>
<td>20000</td>
<td>クラスタ構成用マルチキャストポートを指定します。 ポート番号として指定可能な範囲の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/cluster/notificationInterval</td>
<td>5秒</td>
<td>クラスタ構成用マルチキャスト周期です。 1s以上、2<sup>31</sup>s未満の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/cluster/heartbeatInterval</td>
<td>5秒</td>
<td>クラスタ間でのノードの生存確認チェック周期（ハートビート周期）です。 1s以上、2<sup>31</sup>s未満の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/cluster/loadbalanceCheckInterval</td>
<td>180秒</td>
<td>クラスタを構成するノード間の負荷バランス調整のため、バランス処理を実施するか否かのデータ採取周期を指定します。 1s以上、2<sup>31</sup>s未満の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/cluster/notificationMember</td>
<td>なし</td>
<td>クラスタ構成方式を固定リスト方式にする際に、アドレスリストを指定します。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/cluster/notificationProvider/url</td>
<td>なし</td>
<td>クラスタ構成方式をプロバイダ方式にする際に、アドレスプロバイダのURLを指定します。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/cluster/notificationProvider/updateInterval</td>
<td>5秒</td>
<td>アドレスプロバイダからリストを取得する間隔を指定します。1s以上、2<sup>31</sup>s未満の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/sync/timeoutInterval</td>
<td>30秒</td>
<td>クラスタ間のデータ同期時のタイムアウト時間を指定します。　タイムアウトが発生した場合、システムの負荷が高い、障害発生などの可能性があります。 1s以上、2<sup>31</sup>s未満の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/transaction/notificationAddress</td>
<td>239.0.0.1</td>
<td>クライアントが初期に接続するマルチキャストアドレスです。クライアントにはマスタノードが通知されます。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/transaction/notificationPort</td>
<td>31999</td>
<td>クライアントが初期に接続するマルチキャストポートです。ポート番号として指定可能な範囲の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/transaction/notificationInterval</td>
<td>5秒</td>
<td>クライアントへのマスタ通知用マルチキャスト周期。1s以上、2<sup>31</sup>s未満の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/transaction/replicationMode</td>
<td>0</td>
<td>トランザクションでデータ更新をする時のデータの同期（レプリケーション）方法を指定します。文字列または整数で、 "ASYNC"または0(非同期)、"SEMISYNC"または1(準同期)を指定します。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/transaction/replicationTimeoutInterval</td>
<td>10秒</td>
<td>トランザクションが準同期レプリケーションでデータを同期する際のノード間通信のタイムアウト時間を指定します。1s以上、2<sup>31</sup>s未満の値を指定します。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>　</td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<h2 data-number="7.2" id="ノード定義ファイルgs_nodejson" data-number="7.2"><span class="header-section-number">7.2</span> ノード定義ファイル(gs_node.json)</h2>
<p>ノード定義ファイルでは、クラスタを構成するノードのリソースを初期設定します。オンライン運用では、配置されているリソース、アクセス頻度などから、オンラインで値を変更できるパラメータもあります。逆に一度設定すると変更できない値(concurrency)もありますので注意してください。</p>
<p>ノード定義ファイルの各設定項目の意味を以下に説明します。</p>
<p>初期状態で含まれていない項目も項目名を追加することでシステムに認識させることができます。 変更の欄ではパラメータの変更可否と変更タイミングを示します</p>
<ul>
<li>変更不可　：ノードを一度起動したのちは変更はできません。変更したい場合データベースを初期化する必要があります。</li>
<li>起動　　　：クラスタを構成する全ノードを再起動することで、変更できます。</li>
<li>オンライン：オンライン稼働中にパラメータを変更できます。ただし、変更内容は永続化されないため、定義ファイルの内容を手動で変更する必要があります。</li>
</ul>
<p>ディレクトリの指定は、フルパスもしくは、GS_HOME環境変数からの相対パスで指定します。相対パスは、GS_HOMEの初期ディレクトリが基点となります。GS_HOMEの初期設定ディレクトリは、/var/lib/gridstoreです。</p>
<table>
<thead>
<tr class="header">
<th>GridDBの構成</th>
<th>初期値</th>
<th>パラメータの意味と制限値</th>
<th>変更</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>/serviceAddress</td>
<td>なし</td>
<td>cluster,transaction,syncの各サービスアドレスの初期値を設定。3項目のアドレスを設定せずに本アドレスの設定のみで各サービスアドレスの初期値を設定できる。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/dataStore/dbPath</td>
<td>data</td>
<td>データベースファイルの配置ディレクトリをフルパスもしくは、相対パスで指定する。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/dataStore/dbFilePathList</td>
<td>空リスト</td>
<td>チェックポイントファイル分割時の分割チェックポイントファイルの配置ディレクトリリスト。複数設定可能(例：["/stg01","/stg02"])。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/dataStore/dbFileSplitCount</td>
<td>0 (分割無し)</td>
<td>チェックポイントファイルの分割数</td>
<td>不可</td>
</tr>
<tr class="odd">
<td>/dataStore/syncTempPath</td>
<td>sync</td>
<td>データ同期用一時ファイルの配置ディレクトリのパスを指定。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/dataStore/storeMemoryLimit</td>
<td>1024MB</td>
<td>データ管理用メモリの上限。</td>
<td>オンライン</td>
</tr>
<tr class="odd">
<td>/dataStore/concurrency</td>
<td>4</td>
<td>処理の並列度を指定。</td>
<td>不可</td>
</tr>
<tr class="even">
<td>/dataStore/logWriteMode</td>
<td>1</td>
<td>ログ書き出しモード・周期を指定。 -1または0の場合トランザクション終了時にログ書き込み、1以上2<sup>31</sup>未満の場合、秒単位の周期でログ書き込み</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/dataStore/persistencyMode</td>
<td>1(NORMAL)</td>
<td>永続化モードでは、データ更新時の更新ログファイルの保持期間を指定する。1(NORMAL)、2(RETAINING_ALL_LOGS)　のいずれかを指定。"NORMAL" は、チェックポイントにより、不要になったトランザクションログファイルは削除されます。"RETAINING_ALL_LOGS"は、全てのトランザクションログファイルを残します。</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/dataStore/storeWarmStart</td>
<td>false(無効)</td>
<td>再起動時にチャンクメモリ上限までインメモリ化するかを指定。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/dataStore/affinityGroupSize</td>
<td>4</td>
<td>アフィニティグループ数</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/dataStore/storeCompressionMode</td>
<td>NO_COMPRESSION</td>
<td>データブロック圧縮モード</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/dataStore/autoExpire</td>
<td>false</td>
<td>期限解放が設定されたコンテナのロウを、コールドデータになった後に自動削除するかを指定。false:自動削除しない(長期アーカイブ実行による削除が必要) true:自動削除する</td>
<td>オンライン</td>
</tr>
<tr class="even">
<td>/checkpoint/checkpointInterval</td>
<td>60秒</td>
<td>メモリ上のデータ更新ブロックを永続化するチェックポイント処理の実行周期</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/checkpoint/checkpointMemoryLimit</td>
<td>1024MB</td>
<td>チェックポイント専用書き出しメモリの上限 ※チェックポイント中に更新トランザクションがある場合に必要となるメモリ領域を上限値までプール。</td>
<td>オンライン</td>
</tr>
<tr class="even">
<td>/checkpoint/useParallelMode</td>
<td>false(無効)</td>
<td>チェックポイントを並列実行するかどうかを指定。※並列スレッド数は並列度(concurrency)と同じ数になります。</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/checkpoint/checkpointCopyInterval</td>
<td>100ms</td>
<td>データの更新や追加が行われたブロックをチェックポイント処理でディスクに出力する際の出力処理間隔</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/cluster/serviceAddress</td>
<td>上位のserviceAddressに従う</td>
<td>クラスタ構成用待ち受けアドレス</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/cluster/servicePort</td>
<td>10010</td>
<td>クラスタ構成用待ち受けポート</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/cluster/notificationInterfaceAddress</td>
<td>""</td>
<td>マルチキャストパケットを送信するインターフェースのアドレスを指定</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/sync/serviceAddress</td>
<td>上位のserviceAddressに従う</td>
<td>クラスタ間でデータ同期のための受信アドレス</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/sync/servicePort</td>
<td>10020</td>
<td>データ同期用待ち受けポート</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/system/serviceAddress</td>
<td>上位のserviceAddressに従う</td>
<td>運用コマンド用待ち受けアドレス</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/system/servicePort</td>
<td>10040</td>
<td>運用コマンド用待ち受けポート</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/system/eventLogPath</td>
<td>log</td>
<td>イベントログファイルの配置ディレクトリのパス</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/transaction/serviceAddress</td>
<td>上位のserviceAddressに従う</td>
<td>クライアント通信向けトランザクション処理用待ち受けアドレス(/transaction/localserviceAddressの指定がない場合、クラスタ内部通信向けも兼ねる)</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/transaction/localServiceAddress</td>
<td>上位のserviceAddressに従う</td>
<td>クラスタ内部通信向けトランザクション処理用待ち受けアドレス</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/transaction/servicePort</td>
<td>10001</td>
<td>トランザクション処理用待ち受けポート</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/transaction/connectionLimit</td>
<td>5000</td>
<td>トランザクション処理接続数の上限</td>
<td>起動</td>
</tr>
<tr class="even">
<td>/transaction/transactionTimeoutLimit</td>
<td>300秒</td>
<td>トランザクションタイムアウト時間の上限値</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/transaction/workMemoryLimit</td>
<td>128MB</td>
<td>トランザクション処理でのデータ参照(get、TQL)時のメモリの上限サイズ(並列度ごと)</td>
<td>オンライン</td>
</tr>
<tr class="even">
<td>/transaction/notificationInterfaceAddress</td>
<td>""</td>
<td>マルチキャストパケットを送信するインターフェースのアドレスを指定</td>
<td>起動</td>
</tr>
<tr class="odd">
<td>/trace/fileCount</td>
<td>30</td>
<td>イベントログファイルの上限数</td>
<td>起動</td>
</tr>
</tbody>
</table>
<h1 data-number="8" id="システムの制限値" data-number="8"><span class="header-section-number">8</span> システムの制限値</h1>
<h2 data-number="8.1" id="数値に関する制限" data-number="8.1"><span class="header-section-number">8.1</span> 数値に関する制限</h2>
<table>
<thead>
<tr class="header">
<th>ブロックサイズ</th>
<th>64KB</th>
<th>1MB～32MB</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>文字列型/空間型のデータサイズ</td>
<td>31KB</td>
<td>128KB</td>
</tr>
<tr class="even">
<td>BLOB型のデータサイズ</td>
<td>1GB - 1Byte</td>
<td>1GB - 1Byte</td>
</tr>
<tr class="odd">
<td>配列長</td>
<td>4000</td>
<td>65000</td>
</tr>
<tr class="even">
<td>カラム数</td>
<td>1024個</td>
<td>約7K～32000個(※1)</td>
</tr>
<tr class="odd">
<td>索引数(コンテナ1個あたり)</td>
<td>1024個</td>
<td>16000個</td>
</tr>
<tr class="even">
<td>線形補完圧縮の対象カラム数</td>
<td>100個</td>
<td>100個</td>
</tr>
<tr class="odd">
<td>トリガのURL</td>
<td>4KB</td>
<td>4KB</td>
</tr>
<tr class="even">
<td>アフィニティグループ数</td>
<td>10000</td>
<td>10000</td>
</tr>
<tr class="odd">
<td>解放期限付き時系列コンテナの分割数</td>
<td>160</td>
<td>160</td>
</tr>
<tr class="even">
<td>GridDBノードが管理する通信バッファのサイズ</td>
<td>約2GB</td>
<td>約2GB</td>
</tr>
</tbody>
</table>
<table>
<thead>
<tr class="header">
<th>ブロックサイズ</th>
<th>64KB</th>
<th>1MB</th>
<th>4MB</th>
<th>8MB</th>
<th>16MB</th>
<th>32MB</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>パーティションサイズ</td>
<td>約4TB</td>
<td>約64TB</td>
<td>約256TB</td>
<td>約512TB</td>
<td>約1PB</td>
<td>約2PB</td>
</tr>
</tbody>
</table>
<ul>
<li>文字列型、トリガのURL
<ul>
<li>制限値はUTF-8エンコード相当</li>
</ul></li>
<li>空間型
<ul>
<li>制限値は内部格納形式相当</li>
</ul></li>
<li>(※1) カラム数
<ul>
<li>カラム数の上限には、固定長カラム(ブール型、整数型、浮動小数点数型、時刻型)の合計サイズが59KBまでという制約があります。この制約に当てはまらない場合は、カラム数の上限は32000個になります。
<ul>
<li>例) LONG型カラムのみのコンテナの場合：カラム上限数は7552 ( 固定長カラムの合計サイズ 8B * 7552 = 59KB )</li>
<li>例) BYTE型カラムのみのコンテナの場合：カラム上限数は32000 ( 固定長カラムの合計サイズ 1B * 32000 = 約30KB → 固定長カラムのサイズ制約には当てはまらないので、上限の32000個のカラムを作成できる)</li>
<li>例) STRING型カラムのみのコンテナの場合：カラム上限数は32000 ( 固定長カラムのサイズ制約には当てはまらないので、上限の32000個のカラムを作成できる)</li>
</ul></li>
</ul></li>
</ul>
<h2 data-number="8.2" id="ネーミングに関する制限" data-number="8.2"><span class="header-section-number">8.2</span> ネーミングに関する制限</h2>
<table>
<thead>
<tr class="header">
<th>名前</th>
<th>使用可能な文字</th>
<th>長さの上限</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>ユーザ</td>
<td>先頭が"gs#"で始まる。それ以外の文字は英数字、'_'</td>
<td>64文字</td>
</tr>
<tr class="even">
<td>パスワード</td>
<td>Unicodeコードポイントを文字とする<br>任意個数の文字の列(NULL文字(U+0000)は不可)</td>
<td>64バイト(UTF-8エンコード換算)</td>
</tr>
<tr class="odd">
<td>クラスタ名</td>
<td>英数字、'_'、'-'、'.'、'/'、'='</td>
<td>64文字</td>
</tr>
<tr class="even">
<td>コンテナ名<br>テーブル名</td>
<td>英数字、'_'、'-'、'.'、'/'、'='<br>(ノードアフィニティを指定する場合のみ'@')</td>
<td>16384文字(ブロックサイズ64KB)<br>131072文字(ブロックサイズ1MB～32MB)</td>
</tr>
<tr class="odd">
<td>カラム名</td>
<td>英数字、'_'、'-'、'.'、'/'、'='</td>
<td>256文字</td>
</tr>
<tr class="even">
<td>索引名</td>
<td>英数字、'_'、'-'、'.'、'/'、'='</td>
<td>16384文字(ブロックサイズ64KB)<br>131072文字(ブロックサイズ1MB～32MB)</td>
</tr>
<tr class="odd">
<td>トリガ名</td>
<td>英数字、'_'、'-'、'.'、'/'、'='</td>
<td>256文字</td>
</tr>
<tr class="even">
<td>データアフィニティ</td>
<td>英数字、'_'、'-'、'.'、'/'、'='</td>
<td>8文字</td>
</tr>
</tbody>
</table>
<ul>
<li><p>大文字小文字の区別</p>
<ul>
<li><p>クラスタ名・トリガ名・パスワードは、大文字小文字の区別があります。したがって、例に示すような大文字小文字のみ異なる表記は、異なるものとして扱います。</p>
<pre class="example"><code>例) trigger, TRIGGER
</code></pre></li>
</ul></li>
<li><p>それ以外の名前は、大文字小文字の区別がありません。大文字小文字表記は同一視します。</p></li>
<li><p>作成時に指定された大文字小文字の表記は、データとして保持します。</p></li>
<li><p>TQL構文で名前を引用符"で囲う場合は、大文字小文字の表記を区別した検索を行います。</p>
<pre class="example"><code>例) コンテナ名 SensorData の Column1 を検索する場合
    select &quot;Column1&quot; from &quot;SensorData&quot;   検索可能
    select &quot;COLUMN1&quot; from &quot;SENSORDATA&quot;  &quot;SENSORDATA&quot;というコンテナは存在しないので検索不可
</code></pre></li>
<li><p>TQL構文での名前指定</p>
<ul>
<li>引用符"で囲わない場合は、英数字、'_'(数字は先頭不可)の名前しか記述できません。それ以外の名前を記述する場合には引用符で囲んでください。
<pre class="example"><code>例) select &quot;012column&quot;, data_15 from &quot;container.2017-09&quot;
</code></pre></li>
</ul></li>
</ul>
</div>
</article>
</body>
</html>
